Congratulations to our 2022 Qt Champions!

GL, qtquick, keyevent (builtin qt threads) problems

  • So I am writing my gl game, creating the context on the paintUnder() (of qquickitem), similar to the examples seen for qtquick.

    The issue I'm running into is thread affinity, which didn't occur to me as a problem until I tried to implement the keyPressEvent and attempt to have my game start a new world, which it gets half way and silently does nothing.

    In QML (my ui is done in qml), I do Keys.onBlahPressed{ Client.startSingleplayer() }, for example. And that works fine.

    (right now the entire game is just running in the same thread as the rendering all the game objects and state, network etc. are done just before rendering).

    My suspicions were with thread affinity problems, and I checked QThread::currentThreadID and they are different. So my guessing is that because it works fine in the QML key event, and doesn't work really at all from C++ (yes, the signal is getting fired and received), that it is issues with threading.

    How can I overcome this (preferably without delving into multithreading of contexts..)

    I've also tried triggering it not only directly from the reimplemented keyPressEvent (virtual), but also using signals and slots, and diff. connection types too, but that didn't help. (and queued slots simply do not work from this area).

    Basically, I create my qquickitem subclass, similar in nature entirely to the "Paint Under" qml example/sample. I create a QQuickView subclass of mine in the paintUnder() slot, if it wasn't init'ed already (which would make the gl context, and load the qml main menu, etc), and I render my scene, and update my network etc. all from that slot.

    But then I try to implement the keyPressEvent for my QQuickView subclass, and call into the QQuickItem subclass (client) and it doesn't behave as I would like, obviously. Hence issue.

Log in to reply