Qt Quick Scenegraph and low-level Qt Quick improvements.
NOTE: see comments below. While the overall description is still valid the details have changed somewhat during the past year.
0. Mission Statement
The Qt Quick Scenegraph is not going away, will not merge with any 3D solution, and will continue to provide the fastest, leanest and most optimized approach to get a 2D or 2.5D Qt Quick UI rendered on the widest range of platforms and devices and inside a wide range of 3D engines and VR/AR systems.
1. Improve and embrace headless Qt Quick
With the advent of 3D/VR/AR, the use case of having the 2D UI output by Quick embedded into another engine (which may or may not be Qt based) is becoming the primary one.
A picture is worth a thousand words: https://twitter.com/nezticle/status/888057543012089859
Here Qt still provides the full 2D UI content, but not the rest of the 3D scene or the VR compositor. (or think of Scene2D in Qt 3D, QML Streamer in Qt 3D Studio, and the various usages of QQuickRenderControl out there in the wild)
The headless mode of operation, where Qt Quick scenes are output into textures (or whatever the equivalent with a particular graphics API is), without an active native window, should become the primary mode of operation. Windowing, with targeting an onscreen window surface, should be built on top, and not vice versa like today.
1.1 QQuickScene as the entry point, not QQuickWindow
QQuickRenderControl needs hundreds of lines of code today to get something into, for example, an OpenGL texture. This should be a simple thing to do.
item->window() should die, replaced by item->scene().
1.2 Scenegraph backend configuration on per-scene basis, not application global
For example, rendering on screen with some graphics API should not prevent the application from driving another scene with the software backend, targeting a QImage or printing for instance.
1.3 QQuickWindow, QQuickView, the Window element, etc. should be built on top and should not be mandatory for running a Qt Quick scene
This also involves flexible enough render target abstractions. (texture vs. window surface vs. special cases (QImage for sw), different graphics APIs, etc.)
2. Backends and Modern Graphics APIs
The existing Legacy OpenGL, Software, and OpenVG backends must be kept functional, replacing or rewriting these is not an option.
However, support for a wider range of APIs is inevitable. Qt 5.8's Direct3D 12 backend proves that this is fully feasible, but not without drawbacks. Therefore, Qt 6 is expected to provide proper solutions for the issues discovered during the previous exercises.
2.1 Common Rendering Hardware Interface and Shader Management
[internal note: RHI and shader stuff is currently researched under Dragon6]
Instead of building new, independent backends, let's create an abstraction (command lists, render targets, textures, pipeline states) that provides what the scenegraph needs (and no more), and has backends for all the interesting graphics APIs.
Expected backends for this are: GLES 3.0/GL 3.3, D3D11, Vulkan, Metal (, maybe D3D12)
Note that we are aware of the Khronos 3D Portability initiative but it is not seen as a real solution in Qt Quick context atm.
The ideal target is to use a single language and write shaders just once. (not 2*GLSL + VulkanGLSL + HLSL + MSL, not to mention the vertex shader rewriting headache when batching)
Shaders are to managed centrally, potentially using existing open-source components, like https://github.com/KhronosGroup/SPIRV-Cross.
Reflection (discovering uniforms etc.) is to be managed by a single component, supporting also serialization/deserialization to e.g. binary JSON. No random source code parsing or reflection API usage all over the code base.
Encourage (but do not force) offline operation as much as possible.
Current candidate is Vulkan-style GLSL, compilation to SPIR-V, and doing reflection and translation to other languages via SPIRV-Cross. See https://github.com/alpqr/qtshaderstack17 for the base idea. (which happens to be pretty much what is in the Khronos 3D Portability initiative's initial plans, apparently)
2.3 Material System and Custom Quick Items / Scenegraph Nodes
The RHI/Shader fw also provides the basis for a new material system: in Qt 5 is is effectively impossible to create custom scenegraph nodes with backends other than OpenGL since the material system is inherently tied to GL. This limitation should be lifted, most likely by an alternative, more generic QSGMaterial family of APIs, providing a better cross-platform, cross-gfxAPI story than QSGRenderNode.
3. C++ APIs for the scenegraph
Reach a conclusion on this long-discussed topic.