Details

    • Type: Technical task
    • Status: Reported
    • Priority: P2: Important
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: Qt RHI, Quick: Other
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

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

            Activity

              People

              Assignee:
              lagocs Laszlo Agocs
              Reporter:
              lagocs Laszlo Agocs
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:

                  Gerrit Reviews

                  There are no open Gerrit changes