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

[David Boosalis]

Hi Andre.

Thank you for the reply and advise.  I think you way will fit as I am pretty
sure it is bound by all the drawing done by the GUI since the sockets are in
their own thread.  I will try your suggestion  by caching it and cheeking
the cache with the short and long timers you mentioned.  Your idea of two
timers also gave me the idea to do this on the server. On the server I
currently cache the data till either a certain amount of time transpires
(500 milliseconds) or if the cache is larger then the 1400 bytes (figuring
1500 is the size of the average MTU and allowing up to 100 bytes for packet
header).  I send data which ever occurs first.  I will add one more timer to
make sure that there is some pause before sending out the next group of data
points to the client. Wonder what a resonable pause is - 100 milliseconds ?


Of course any other comments are suggestions are welcomed.

-David


On Sat, Aug 14, 2010 at 11:09 AM, Andre Somers <andre at familiesomers.nl>wrote:

>  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é
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100814/87886b8c/attachment.html