[Qt-interest] Advise on how to prevent GUI lockout

[Andre Somers]

  Op 14-8-2010 18:06, David Boosalis schreef:
> A while back (it was more then once) I was asking how to speed up 
> delays found between QTcpServer and QTcpSocket.  Well the problem was 
> really more of a Tcp issue.  The solution was to use multiple sockets 
> and distribute the date sent among them.  This works great, and in a 
> few corner cases it works to good. The data rate overwhelms the poor 
> Qt application causing the GUI to be locked and frozen as it cannot 
> keep up with all the draw requests (The CPU usage for the application 
> goes up to 100%).
>
> I would like to know what is the best practise for handling this kind 
> of problem. Ideally I'd like to peak at the event queue to see how 
> many request are pending. If to many,  tell the class holding the 
> socket to start buffering the data.  The QAbstractEventDispatcher 
> class looked like it might help me but there are not any examples of 
> this, and maybe there is an easier way.
>
> Has anyone dealt with this issue, if so I 'd appreciate hearing how 
> you resolved it.
I'm not sure from your description where the problem occurs exactly. 
Does processing the incomming data take too much time and is that 
suffocating the event queue so paint events don't come through fast 
enough any more, or does your processing push so many separate updates 
to the GUI that you drawn in the number of GUI updates?

I don't know how your sockets are triggering the paint events, but 
perhaps you can limit the rate at which the GUI is updated. If a very 
small delay is acceptable, you could use a system I used myself in the 
past. Instead of having changes that cause redraws take effect 
immediately, you buffer the data or the events that cause the change so 
you can process more than one at the time. Now, you trigger two timers, 
one with a short, and one with a longer timeout. Both the timers will, 
on timeout, trigger the update. When data arrives that triggers a 
timeout, you start both timers if they are not already active. If they 
are active, you stop and restart the short timer but not the long one. 
On timeout, when the redraw is triggered, you stop both timers. This 
way, updates will not be posthoned longer than needed, but at the same 
time, they will never be postphoned too long either.

The above would work to aleviate issues with too many GUI updates, but 
not with the first possible cause of your issues.

André