[Interest] Optimizing performance with hundreds of widgets

[Gibbs, Matt]

Hi Elvis, thanks for your thoughtful reply.

I agree, the 500 label test is pretty silly, and would not make a very useful display.  However, we *do* often use panels with very large numbers of widgets.  An example of a display from our existing (non-Qt) control system looks like this:

http://slac.stanford.edu/~mgibbs/li30-magnets.png  (Right now our accelerator is in a maintenance period, hence all the yellow, purple, and red alarm boxes you see.  In normal running, most everything has no alarm.)

These displays are almost certainly overwhelming to a brand-new user, but the users for these screens are experts who know the system very well, know what to look for, and appreciate the massive data density that they provide.  We structure our displays hierarchically: top-level overview screens that represent entire systems as a single indicator, mid-level screens which display summary signals for subsystems, displays that show the most useful signals for devices in a subsystem (like this example), and finally, device detail screens that show all signals for a single device.  You drill down through the displays from the top-level down to a single device, so we do something similar to what you are suggest.

That said, many of the text labels (and sliders) you see on this example display are connected at signals that refresh at 10 Hz, and there are a bunch - I count something like 180 widgets on this display that could potentially be updating if their signals were all changing at the same time.  This isn’t too far removed from my label test, so I think advice for how to optimize this case is not irrelevant.

Cheers,
—Matt

> On Feb 21, 2017, at 04:33, Elvis Stansvik <elvstone at gmail.com> wrote:
> 
> 2017-02-21 13:27 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>> 2017-02-15 18:28 GMT+01:00 Gibbs, Matt <mgibbs at slac.stanford.edu>:
>>> Hi All,
>>> 
>>> I’m working on a Qt-based project to display rapidly updating information from a control system.  I want to display hundreds of signals, each updating at about 10 Hz.  As a performance test, I’ve thrown 500 Labels in a grid layout, and fire a timer every 100 ms which calls setText on each label.  This ends up being surprisingly CPU-intensive: on reasonably modern hardware (2012 MacBook Pro), I use 70% of one CPU.  This doesn’t leave me much overhead to do anything else.
>>> 
>>> Are there any best practices to reduce CPU usage in this case?
>> 
>> Hm, I don't really have a good answer when it comes to optimizing it
>> the way you've stated it, but lets get a little philosophical instead:
>> What human operator of your GUI is going to be able to process all
>> this visual information? I would have a hard time monitoring even 5
>> labels of text updating at that rate.
>> 
>> My recommendation would be:
>> 
>> 1. Consider if your really have to show all these sensors, or if the
>> information they're conveying can be aggregated in some way.
>> 2. If you really need to visualize them all at once, consider a
>> simpler presentation than the numerical, such as a bar (should be
>> cheaper to redraw than a changing text).
>> 
>> Regarding 1, if the sensors can be grouped in some logical way, you
>> can present a collection of sensor groups instead. Regarding 2, if the
>> user wants to look closer at a single sensor, or maybe a (reasonably
>> sized) group of sensors, you could build some UI for that.
>> 
>> It would help to know a little more about the user story, is this for
>> monitoring a system for failures? If so, I think the rule of thumb is
>> that if nothing is out of the ordinary, the system should not look
>> visually "busy" (no big movements or bright colors, just subtle
>> gray/static text). That allows you to use visual movement and bright
>> colors for error conditions / anomalies. But yea, it would help to
>> know more about what the GUI is for :)
> 
> Another powerful UI design principle is (as I hinted at) "drill down"
> UIs -- find some way of aggregating the information, and let the user
> drill down deeper if he/she wants to know/see more.
> 
> The fidelity you're aiming for (500 numbers, presented numerically @
> 10 Hz) is too much bandwidth, not only for your MacBook, for also for
> any human.
> 
> Elvis
> 
>> 
>> Hope that helps a little, even if it wasn't what you asked for.
>> 
>> Elvis
>> 
>>> 
>>> Cheers,
>>> —Matt
>>> 
>>> Matt Gibbs
>>> SLAC Accelerator Operations Group
>>> mgibbs at slac.stanford.edu
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest