Qt Quick Scenegraph in Qt 6

Qt Quick Scenegraph and low-level Qt Quick improvements.
(rewritten 11/2018 to reflect the current state of things)

Mandatory:

Backends and Modern Graphics APIs

The software backend must stay functional as today. The default rendering path (which today uses OpenGL directly) is to be replaced to render on top of the RHI developed in QTBUG-70287. The OpenVG and D3D12 backends are likely removed in Qt 6.

Shaders, resource binding, material system

As a consequence, there will be a single shading language in use. Likely Vulkan-flavor GLSL (but could be that we will drift towards HLSL long term), with (mostly offline or build-time) compilation to SPIR-V, reflection data generation, and translation to other languages.

Some material-related APIs will need to change (QSGMaterialShader is not suitable, obviously). Providing data to the shaders will slightly differ from today. (uniform buffers will be more prevalent)

Providing shader code will likely move towards baking and compiling offline as much as possible, inline code should still be supported as much as possible but not promoted as the primary way of doing things.

Closer 3D integration

It is not yet clear how the primary 3D story will look like in Qt 6. The main goal is however to unify both on the engine and tooling level as much as possible.

Optional:

C++ APIs for the scenegraph

...

Shader graphs for ShaderEffects and materials

If QTBUG-71916 gains traction, the ShaderEffect item and any scenegraph material is a prime candidate for consuming (programatically or visually generated) shader graphs (translated to the RHIs single shader language).

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.

The animation fw would need enhancements too, the global animation driver is not ideal.

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.

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.)

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.