1
votes

I have two (alternative) functions working on data supplied by a sensor. The functions run in their own thread and emit a signal when the result is ready. This signal is connected to a slot of a UI widget, displaying the result. With one of the functions, this works well. When using the other however, the GUI starts to lag and soon freezes.

QDebug shows that data is still being processed though.

When running the code in the GUI-thread, there is no problem.

Might the problem be that the worker-thread produces data faster than the UI can draw it, leading to some lag due to the Qt::QueuedConnection? If so, what alternatives do I have? If not, what else can I check?

2
We'd really need some code to help you out on this one. My only wild guess is that the worker thread is spamming the UI thread with more results than it could possibly handle. Can you put a throttle on it for testing and see if it makes a difference?Dave Mateer
After including a big, unnecessary loop, it runs much smoother. So yes, this would seem to indicate a problem with the worker thread being too fast, as you and I suspected. What can I do now?user1041903
I'm moving the discussion to an answer, as it seems we have confirmed the root cause....Dave Mateer

2 Answers

3
votes

It would appear that the worker thread is spamming the UI thread, filling up the main event loop so that GUI events have a hard time getting processed.

Without seeing some of the code in the worker thread, it is difficult to recommend a solution. At the end of the day, you only want to emit your signal at specified intervals.

You may have some luck with the QTime class. Each time your signal is emitted, call QTime::start and then check the QTime::elapsed value. Only when it is above a certain threshold emit your signal and reset the timer.

If you can throw away the intermediate sensor values, that's ideal. If you need them all, you would have to add them to a QVector or something and send them all at once in the signal.

Even better is if you can only poll the sensor itself at regular intervals. The QTimer class might be useful in this case--have it poll the sensor (and emit the signal) every time it "ticks".

0
votes

I actually just managed to find a solution: The data processing, done in a separate thread was polling the sensor class way to often. Therefor, the signal to the UI thread was emitted several times for each sample from the sensor.

By including a QWaitCondition into the processing thread, I managed to get down to a more reasonable refresh rate.

Nevertheless, many thanks for your answer.