QQuick3DTexture's sourceItem support is incompatible with the threaded render loop since it does not comply with basic Qt Quick scenegraph rules that are well known since Qt 5.0. (e.g. that QSG* and QQuick*, just like QSSG* and QQuick3D*, cannot be mixed together)
- It needs a system where render thread operations (and related signal connections) are performed correctly, touching only QSG* and QSSG* data. QQuick3DTexture itself lives on the gui thread, and neither it nor other components such as the scene manager must manage QSG* data, such as QSGTexture. (they can of course hold references, although discouraged, as long as said references are carefully managed)
Any signal connection to QQuickWindow signals that are documented to be emitted on the render thread must use Qt::DirectConnection. This also means that the slot/lambda is called on the render thread. There is a special case with the beforeSychronizing and afterSynchronizing signals, which are emitted on the render thread but with the gui thread blocked (i.e. like updatePaintNode/updateSpatialNode) - the slot/lambda for those can access data living in gui objects (QQuick3D* instances).
- Additional care is needed for dynamic changes, such as assigning another value or null to sourceItem, or just destroying the associated Item. This is supposed to be in place mostly but has subtle issues, e.g. due to issuing an updateTexture() (render thread) while the gui thread destroys the QSGLayer upon acting on the destroyed signal (see
- It should be possible to get the contents of the QSGLayer rendered right away. The current solution of deferring until the first update in the sub-scene completes (in the next frame probably?) is not quite ideal.
- Assigning an Image as sourceItem does not work. (this is a textureProvider but not a QSGDynamicTexture)
- Then there are some not quite ideal choices, such as performing operations in every updateSpatialNode even if nothing has changed. Additionally, the class comes with 8 TODO notes. Some of these make no sense, while others may be valid. This should be brought down to 0.