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

[David Boosalis]

Hi Ross.

Sometimes and these are really corner cases, the server can send me an
inordinate amount of data.  This data can be a mixture of strings, floats,
and integers.  After reading the data from the socket, I then add it to a
QTreeView.  While that data may be arriving really fast, it is the tree
updating that gets expensive.  There are multiple views each with its own
set of sockets that get data from the server.  Some of these views can see a
lot of data all at once depending how volatile things are on the server.

Your fixed frame rate approach is intriguing.  But if I am constantly make
rows of data and deleting old ones, how do I control the paint method with a
timer.  Maybe is something like this:

void MyTreeView::paintEvent(QPaintEvent *pe)
{
 if (okToPaint) {
    QListTree::paintEvent(pe);
    okToPaint = false;
  }
}

void MyTreeView::timerSlot()
 {
   okToPaint = true;
 }
}

When things are running normally, I am using 20-30% of my laptop's CPU which
is running Vista.  And while it seems high it is really OK as this is a
dedicated system for this application.  Maybe I just need to specify minimum
hardware requirements for the user.


Thank you for taking the time to offer some suggestions, any follow up
thoughts are of course welcomed.


-David




On Sat, Aug 14, 2010 at 11:52 PM, Ross Bencina
<rossb-lists at audiomulch.com>wrote:

>  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 <david.boosalis at gmail.com>
> *To:* QtInterest <qt-interest at trolltech.com>
> *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/55fbefde/attachment.html