Important: Please read the Qt Code of Conduct -

How do I pass keypress events to QQuickFramebufferObject::Renderer?

  • I've followed the example here:

    It lets me render things using c++ and display them using qml.

    From the documentation of "QQuickFramebufferObject::Renderer::synchronize()":, I read the following:

    bq. This function is called as a result of QQuickFramebufferObject::update().
    Use this function to update the renderer with changes that have occurred in the item. item is the item that instantiated this renderer. The function is called once before the FBO is created.
    For instance, if the item has a color property which is controlled by QML, one should call QQuickFramebufferObject::update() and use synchronize() to copy the new color into the renderer so that it can be used to render the next frame.
    This function is the only place when it is safe for the renderer and the item to read and write each others members.

    So how do I give commands (like translate left) to the renderer, do I have to buffer the commands myself until synchronize is called, then reset the buffers afterwards? Is there a more simple (and safe) solution? Perhaps using signals?

  • bq. Perhaps using signals?

    Using signals sounds like a good idea to me. I would go ahead and connect QML signals to Cpp signals/slots for that. These signals/slots can handle your renderer.

  • While you can handle key presses in the renderer using signals, it isn't exactly a clean separation of rendering and other logic.

    Ideally the renderer, that operates on the render thread, would perform rendering only based on the state it receives in the synchronizing step. All other logic, like handling key events and updating the state based on them, should stay on the gui thread. The state is then transferred in synchronize().

  • Forgive my ignorance, but I'm a little new to the concept of having completely separate rendering code. I'm used to being able to read from the logic section during rendering (i.e camera position and rotation, position of objects in the scene etc).

    From what you're suggesting, it sounds like I need to copy over the entire state of the logical representation during each call to synchronize, or do some kind of bookkeeping of dirty objects, is that right?

    To me all that synchronization seems like a headache and a bit over the top for the kind of application I'm developing, and that's why I wanted to just get the keypresses in the same thread, so I wouldn't have to worry that much about communication between threads.

    I'm grateful for the advice though. And I'm still considering keeping the logic in the other thread.

Log in to reply