QQuickFramebufferObject evolution

Does QQuickFramebufferObject need a replacement? What is the story here going forward? In 5.15 QQuickFramebufferObject is functional both with direct OpenGL and when rendering through QRhi and its OpenGL backend, but results in an empty item when running on other backends.

This is also what we will have in 6.0, QQuickFbo is documented to be only functional with OpenGL.

If we want to keep feature parity, a smarter alternative needs to be introduced (QQuickNativeRendererItem or similar), that allows integrating custom rendering code for the API that matches active QRhi backend. (such apps are assumed to force one single QRhi backend)

Alternatively:

Is what we have now - the ability to do a custom item+node+createTextureFromNativeObject, demonstrated in the metaltextureimport example, for instance - sufficient? QQuickFBO is merely a convenience to avoid the need to write custom SG nodes.

Alternatively:

Figure out the grand QRhi story, and if it becomes at least semi-public some day, then add a QQuickRhiItem (and QRhiWidget) and that's it.