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

Ross Bencina rossb-lists at audiomulch.com
Sun Aug 15 08:52:41 CEST 2010


Hi David

I think Andre's suggestion is a good one, but there are a few things that are unclear from your description:

- What exactly is causing the 100% CPU load? Qt QPainter drawing? or your application code for processing incoming socket data?

If it is the painting, you could consider a fixed frame rate approach (always update the data when new socket messages arrive, but only redraw the GUI at a constant (slower) frame rate triggered by a QTimer.

If your data changes are just calling update() on a QWidget or equivalent to trigger a paintEvent update, it shouldn't really matter if the CPU load is at 100% since it will just be refreshing as fast as it can -- which might be what you want. In general mouse events and other things should still get priority over paint events so you shouldn't be locked out -- if you are then perhaps something else is wrong? And you should be calling QWidget::update() because doing painting outside a paintEvent is a Bad Thing.

If your drawing is _really_ expensive (say more that 100ms to render an update) you could consider running the rendering to a QImage in a separate thread and then copying the QImage to the screen when it's ready. That way the GUI remains responsive even while the new data is being rendered (assuming your thread priorities are correct). -- this depends on using software rendering,  I'm not sure you could get OpenGL accelleration to an offscreen QImage in a separate thread..

Ross.

  ----- Original Message ----- 
  From: David Boosalis 
  To: QtInterest 
  Sent: Sunday, August 15, 2010 2:06 AM
  Subject: [Qt-interest] Advise on how to prevent GUI lockout


  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.

  Thanks
  David 


------------------------------------------------------------------------------


  _______________________________________________
  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/20100815/e64f0a28/attachment.html 


More information about the Qt-interest-old mailing list