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


      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.


      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:

      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.


          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              lagocs Laszlo Agocs
              lagocs Laszlo Agocs
              3 Vote for this issue
              32 Start watching this issue



                  Gerrit Reviews

                  There are no open Gerrit changes