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

[Ross Bencina]

Hi David

OK, I understand a bit better now.

>From what you say it may be that the cause of yoru CPU issues is not painting but the manipulation of the tree model data structure. You should do some profiling on this. I'm not convinced that the solutions we've been offering are the correct ones for this case. Are you updating the tree or just changing node values?

If you're using a QTreeView (not a QTreeWidget) you might be able to avoid a lot of update overhead by careful design of a custom tree model. One possibility would be to filter your incoming data and only process the data which applied to the currently visible part of the tree -- but really, most of that should be handled by the QTreeView if you've coded your model update notifications correctly.


Ross.

  ----- Original Message ----- 
  From: David Boosalis 
  To: Ross Bencina 
  Cc: QtInterest 
  Sent: Monday, August 16, 2010 2:30 AM
  Subject: Re: [Qt-interest] Advise on how to prevent GUI lockout


  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 
      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/20100816/5487796b/attachment.html