View source for QtCS2017 QQSG

Qt 6 Changes epic ( https://bugreports.qt.io/browse/QTBUG-62425 ) has a Qt Quick Scenegraph subtask: https://bugreports.qt.io/browse/QTBUG-62439

Basis of discussion.

- background story. Qt 3D Studio likely based on Qt 3D in the future, it has been brought up if Qt Quick should also be unified to use the same underlying engine (i.e. Qt 3D) Also, new graphics APIs coming, all engines have to support multiple ones in the future, why not unify?

- however, Qt Quick is more: software (QPainter, not necessarily raster paint engine) backend, OpenVG

- software backend (QPainter) seen as highly valuable

- Qt Quick also targeting low-end (bad GPU, no GPU, rumors about ports to MCU class systems even) Putting in a 3D engine with all bells and whistles is no-no.

- Maintaining a separate Qt Quick 2 while having a new "Qt Quick 3" based on some other rendering engine is a no-go.

- Embedding type of use cases more and more relevant: QQuickRenderControl, integration with foreign engines (e.g. Qt Quick in Unity 3D in VR, etc.). Make this easier: Can QQuickWindow be decoupled from the actual scene?

- alternative to "QQuickScene" proposal: extend QQuickRenderControl instead.

- Reduce global state (per-scene, not per-application scenegraph backend and render loop/animation system). Likely good, no further comments.

- New backends for Vulkan, Metal ?

- D3D12 experiment shows it is a lot of work.

- Backend infra still incomplete: one cannot do a new backend that 100% on-par with OpenGL (custom materials story lacking, public API for material shaders and such is tied to OpenGLisms, need new APIs that are more generic).

- Presented the RHI idea: new backends should use a common graphics abstraction layer.

- Ideal target is to expand this to the whole of Qt (Qt 3D, etc.). (very big task though; just focusing 2D in the beginning makes it a lot easier) 

- Shaders. "Common language" experiment at https://github.com/alpqr/qtshaderstack17

- Was questioned if this is really suitable and stable. Wouldn't it be better to stay with different languages per-API, but add a whole new option on top: node-based shader editing (with visual tooling). Currently being prototyped in Qt3D.

- C++ scenegraph API was brought up. Not sure about it. Materials story shows that existing public APIs are a problem even. New graphics API stuff and other proposed changes likely need no significant restructuring but it's too early to tell.

- Note: nothing in the Jira task is committed to. Playing with ideas while busy with other stuff.