Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. Qt: Sharing GL objects between several QQuickFramebufferObject's - on which thread to create the shared GL objects?
QtWS25 Last Chance

Qt: Sharing GL objects between several QQuickFramebufferObject's - on which thread to create the shared GL objects?

Scheduled Pinned Locked Moved Unsolved QML and Qt Quick
multithreadopengl
8 Posts 2 Posters 3.6k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Stefan Monov76S Offline
    Stefan Monov76S Offline
    Stefan Monov76
    wrote on last edited by Stefan Monov76
    #1

    I have several QQuickFramebufferObjects between which I want to share some GL objects (shaders and VBOs mainly). My initial plan was:

    • Create a class SharedGLData to hold the shared object
    • Instantiate this class on the stack in C++'s main()
    • Pass a pointer the object to QML via ctx->assignRootProperty or something
    • Pass the object as a property to the QML items of type SharedGLData
    • Access the pointer from C++

    But that means I'd be creating GL objects on the main thread and later access them on the render thread. I'm pretty sure that's forbidden, for example see here where it says:

    QOpenGLContext can be moved to a different thread with moveToThread(). Do not call makeCurrent() from a different thread than the one to which the QOpenGLContext object belongs.

    Is it ok to follow my initial plan or is there a way to create shared GL objects on the render thread?

    A possible hack would be to put the shared stuff into a singleton that gets initialized on first use, and make my first use be directly from the rendering code. But that's a hack.

    Another idea is to call moveToThread on the QQFBO's GL context to move it to the main thread, instantiate SharedGLData, then move the GL context back to the render thread. But I don't have a pointer to the render thread...

    kshegunovK 1 Reply Last reply
    0
    • Stefan Monov76S Stefan Monov76

      I have several QQuickFramebufferObjects between which I want to share some GL objects (shaders and VBOs mainly). My initial plan was:

      • Create a class SharedGLData to hold the shared object
      • Instantiate this class on the stack in C++'s main()
      • Pass a pointer the object to QML via ctx->assignRootProperty or something
      • Pass the object as a property to the QML items of type SharedGLData
      • Access the pointer from C++

      But that means I'd be creating GL objects on the main thread and later access them on the render thread. I'm pretty sure that's forbidden, for example see here where it says:

      QOpenGLContext can be moved to a different thread with moveToThread(). Do not call makeCurrent() from a different thread than the one to which the QOpenGLContext object belongs.

      Is it ok to follow my initial plan or is there a way to create shared GL objects on the render thread?

      A possible hack would be to put the shared stuff into a singleton that gets initialized on first use, and make my first use be directly from the rendering code. But that's a hack.

      Another idea is to call moveToThread on the QQFBO's GL context to move it to the main thread, instantiate SharedGLData, then move the GL context back to the render thread. But I don't have a pointer to the render thread...

      kshegunovK Offline
      kshegunovK Offline
      kshegunov
      Moderators
      wrote on last edited by kshegunov
      #2

      It sounds to me you want to use QOpenGLContext::setShareContext, ... so why the long way around? I'm by no means an GL expert but as far as I understand it, you just create one context in one thread, and then create another one that shares the first's resources in the other thread.

      Read and abide by the Qt Code of Conduct

      Stefan Monov76S 1 Reply Last reply
      0
      • kshegunovK kshegunov

        It sounds to me you want to use QOpenGLContext::setShareContext, ... so why the long way around? I'm by no means an GL expert but as far as I understand it, you just create one context in one thread, and then create another one that shares the first's resources in the other thread.

        Stefan Monov76S Offline
        Stefan Monov76S Offline
        Stefan Monov76
        wrote on last edited by
        #3

        @kshegunov: Thanks, that sounds reasonable. But that would mean creating a GL context for every QQFBO, which can be slow. I need really fast creation of new QQFBO items.

        kshegunovK 1 Reply Last reply
        0
        • Stefan Monov76S Stefan Monov76

          @kshegunov: Thanks, that sounds reasonable. But that would mean creating a GL context for every QQFBO, which can be slow. I need really fast creation of new QQFBO items.

          kshegunovK Offline
          kshegunovK Offline
          kshegunov
          Moderators
          wrote on last edited by
          #4

          According to the documentation FBOs are one of the objects that can be shared, so as I see it you just create whatever is you need in the one thread, in the second you only call QOpenGLContext::setShareContext before you call create.

          Read and abide by the Qt Code of Conduct

          Stefan Monov76S 1 Reply Last reply
          0
          • kshegunovK kshegunov

            According to the documentation FBOs are one of the objects that can be shared, so as I see it you just create whatever is you need in the one thread, in the second you only call QOpenGLContext::setShareContext before you call create.

            Stefan Monov76S Offline
            Stefan Monov76S Offline
            Stefan Monov76
            wrote on last edited by
            #5

            @kshegunov: QQFBO != FBO. :)

            FBO is an OpenGL object, QQFBO is a Qt Quick visual item (subclass of QQuickItem) that you can subclass to implement a custom QQuickItem by drawing with OpenGL to a FBO that is later itself drawn to the screen by Qt.

            In light of that, I don't think your last answer helps me, sorry.

            kshegunovK 1 Reply Last reply
            0
            • Stefan Monov76S Stefan Monov76

              @kshegunov: QQFBO != FBO. :)

              FBO is an OpenGL object, QQFBO is a Qt Quick visual item (subclass of QQuickItem) that you can subclass to implement a custom QQuickItem by drawing with OpenGL to a FBO that is later itself drawn to the screen by Qt.

              In light of that, I don't think your last answer helps me, sorry.

              kshegunovK Offline
              kshegunovK Offline
              kshegunov
              Moderators
              wrote on last edited by
              #6

              Fine.
              Have you read this one:
              https://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/

              Might be of help here.

              Read and abide by the Qt Code of Conduct

              Stefan Monov76S 1 Reply Last reply
              0
              • kshegunovK kshegunov

                Fine.
                Have you read this one:
                https://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/

                Might be of help here.

                Stefan Monov76S Offline
                Stefan Monov76S Offline
                Stefan Monov76
                wrote on last edited by
                #7

                @kshegunov: Thanks, I have, but unfortunately it contains nothing on this matter.

                kshegunovK 1 Reply Last reply
                0
                • Stefan Monov76S Stefan Monov76

                  @kshegunov: Thanks, I have, but unfortunately it contains nothing on this matter.

                  kshegunovK Offline
                  kshegunovK Offline
                  kshegunov
                  Moderators
                  wrote on last edited by
                  #8

                  Well, I have no other ideas, sorry.

                  Read and abide by the Qt Code of Conduct

                  1 Reply Last reply
                  0

                  • Login

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • Users
                  • Groups
                  • Search
                  • Get Qt Extensions
                  • Unsolved