XMLWordPrintable

    Details

      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.

      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.

        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:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Gerrit Reviews

                  There are no open Gerrit changes