How to update GUI promptly with data sent from threads

[Eos Pengwern]

In my application, several threads generate graphical data which they then send (via signals and slots) to the main GUI thread for display. Most of the time things work pretty smoothly, but on occasions things seem to 'hang' and the GUI can go for several minutes without being updated, even though the threads may still be sending data tens of times every second. It's as though the main GUI thread is failing to action its event queue properly.

Now, I am familiar of course with the use of QCoreApplication:: processEvents() within a thread, during time-consuming actions, to make sure that the thread acts upon its own event queue. However, how do I force my main GUI thread to process its events properly when it has nothing else to do except lie idle until it receives a signal from one of its threads to display some data?

Alternatively, is there some other possible explanation (and remedy) for this frustrating behaviour?

Thanks,
Stephen.

[tbscope]

When the eventloop has events to dispatch, they will be distpatched immediatly. There is no reason why the eventloop would wait sending them.

However, other processes and threads might put the main eventloop into a bottleneck and prevent it from dispatching the events.

One tip I can give you is to make your main thread the most important thread (if that is the goal of course). Your rendering threads don't matter, make them less important. This way, the main event loop has priority and not your threads.

Another tip is to investigate where the bottleneck is and try to solve it.

Also, be very careful with signals and slots accross threads. You need to put a complete QObject with its own signals and slots inside the thread. QThread itself lives in the main thread.

[Eos Pengwern]

Thank you.

The graphics-generating threads are already assigned "Low Priority", and I'm unsure how to look for a bottleneck. I already know that the system behaves quite differently in 'release' mode from in 'debug' mode because the thread synchronisation is all completely different - one of the threads is receiving images over an ethernet connection, so can't easily be 'slowed down'.

I have a support subscription, so this may be one to ask them about...

Stephen.

[tbscope]

and I'm unsure how to look for a bottleneck.

Debugging. There are a lot of techniques and programs you can apply to find where the problem is.
The most simple technique is to add qDebug() statements in your code. You can put your program through a tracer and log the time it takes to perform a function or statement. Etc.

one of the threads is receiving images over an ethernet connection, so can't easily be 'slowed down'.

You can but this is most likely not the problem.

If the main thread gets unresponsive, than the problem is most likely in the main thread itself, not any of the other threads.