How to smartly update the UI from the working thread?

wxPython Users
#1

Hi,

I have written an application where the UI receives data from a working thread. The working thread is in fact a communication thread (using a socket) but this does not change my problem.
So, in my application, there is the main thread that manages the UI and another one that provides data to be displayed by the UI. The working thread uses pub.sendMessage(wx.CallAfter, …) to send data to the UI thread. Essentially, the UI components that are updated with data are TextCtrl.
All in all, this works, but… when the working thread sends too many data to the UI thread, the UI becomes unresponsive. I don’t have any numbering for “too many” but it is not so high. It looks like it is quite variable. The data throughput varies over time. At startup, it is high, then is low. It can be high from time to time. Unresponsive means Windows tells the application is unresponsive, UI is not updated and user inputs are not working.
I’ve tried many strategies to avoid this problem without success. Either the UI is unresponsive at some point, either the data rate is too low.
I have tried to put the working thread in a process. I use a queue to transfer data and a thread to read the queue and give data to UI thread (using pub.sendMessage(wx.CallAfter, …)).
The problem is still there.
So, how can I automatically regulate the data throughput sent to the UI thread to always have a responsive UI and with the higher throughput possible ?

All ideas are welcome :wink:

Nicolas

#2

I finally found a solution to my problem.
I bind a callback on EVT_IDLE events in the main window. The callback releases a BoundedSemaphore (bounded to 1). The working thread acquires the BoundedSemaphore before publishing data to the UI.
This way, the UI is always responsive and the data throughput is automatically regulated. :slight_smile:

Nicolas

#3

Yes, that sounds like a good approach. The key point in dealing with a high rate of data changes/updates is to not require an actual update of the UI for each and every new data change, but rather to periodically update the UI to reflect the current state of the data. As long as the UI updates happen often enough then the eye can’t really tell the difference between that and being able to do an update for every individual data change.

#4

In my case, I must display all values since my app is part of a real time logging system. It displays values logged by many other apps (as I already said, the working thread is managing the communication).
Most of the time, there’s not so much to display. But sometimes, there’s a burst, especially when the app starts.

#5

You can still display all items, even if you are not updating the UI each time there is a new item available. What’s possible depends on what widget you are using and the nature of the data, but in general the approach I was trying to explain is that when a new item is received you just add it to some data collection and then signal the UI that new data is available. It’s possible that by the time the UI is able to react to that signal that more items have arrived, so it just does whatever it needs to do with all the new items.

So, in other words, when the rate is slow the UI update will probably just display 1 additional item shortly after it arrives. When the arrival rate is high then the UI update may have some N number of new items waiting for it and so it adds all N to the UI. Depending on the widgets it might make sense to use Freeze and Thaw to delay the refresh of the widgets until all N have been added.

Anyway, since your implementation is working for you then you can ignore this. I was just trying to present the general principles for dealing with data bursts.

#6

That’s interesting. I didn’t know Freeze and Thaw. I’ll try to use them. I’m sure I can get a better throughput using them.
Thanks Robin.

#7

I quickly tried Freeze and Thaw. The UI is displays data faster but I get side effects. So I won’t use them for now.
Thanks again Robin.