Multi thread OpenGL and QtQuick

I quite like QtQuick even though there are elements of it that can be a little tedious at times. I’ll put that down to being a very young tool that needs some refinements, and some useful libraries to go with it. The biggest win for me though is how nicely it integrates with OpenGL. There are a few examples out there and I’ve had quite some success following the QmlOgre demo.

However, I ran into a problem where our rendering was far too slow. Basically it is running compute shaders against quite a large gridded data set and without a lot of trickery this can’t be done in real time. Least not on my silly little GPU. The result was that the QtQuick rendering thread was being delayed by our rendering. This badly affected the UI.

My solution was to create a third thread, after the main thread and QtQuick rendering thread, to house our rendering.

Thread Controller
This is a QThread that I use to run an event loop, and house the RenderWorker. Just instantiate one of these, and pass the worker through. The method launchWorker starts up the event loop and blocks until the thread and finished starting.

Derives from QSGGeometryNode and is created in RenderItem::updatePaintNode. All it does is link to a GL texture which looks like this:

This class is a QObject derived class that ends up living within ThreadController. It has three slots initialize, resize, and render. The trick here is that we create the texture and render to it via a framebuffer. The texture id created here is passed through to RenderNode that then creates a QSGTexture that references it. Looks a like this:

Any time we resize our window we have to update the texture id also

Rendering is a normal framebuffer render

RenderNode is the QQuickItem derived class used in QML. Its basically where the engine is instantiated and everything begins. This part is still a work in progress but what I have here works. The main bit is this:

So, I create the RenderWorker and bind up some events. Specifically I want QQuickItem::update to be called whenever we have finished rendering a frame.
Then initialize is invoked using a BlockingQueuedConnection so that the calling thread waits until it has completed. At this point we know our texture exists and we can use it in QtQuick.
Anytime a resize happens we again use a BlockingQueuedConnection to update the texture.
Finally render is called using a QueuedConnection.

There are a couple of problems and things I don’t like that I’ll be taking a look at.

  • I want to switch out the use of invokeMethod where possible. Now that Qt5 can handle templated signal slots I vastly prefer those versus using strings. For one you get compile errors when the slot doesn’t exist
  • The screen flickers during a resize. This is because of the delay between creating a new texture, and actually rendering to that texture. In the time being the QtQuick has gone off and used your brand new texture to paint to the screen. You’ll notice in the resize method of RenderWorker I’m clearing it to black as an interim solution.
  • I’m concerned about the way I’m using signals and slots to communicate with the RenderWorker. I suspect in some cases it could end up running almost a frame behind based on when the events get processed. I’ll need to inspect this more
Loading Facebook Comments ...

Leave a Reply

Your email address will not be published. Required fields are marked *