QWidget::update() efficiency with hierarchy of custom widgets

[SixDegrees]

Task Manager is worthless for real-time CPU monitoring.

Also, CPU usage is a tricky metric. Is there an actual performance problem in your application? If not, measuring CPU activity isn't going to tell you much; it's generally reported as some sort of average over a time interval, so if the interval is long enough the percentage will drop, while if the interval is made too short it will report 100% activity. top can be extremely misleading in this regard.

Unless your program is utilizing 100% of the CPU for extended periods of time, I wouldn't pay any attention to this metric, particularly if the UI is responsive and updates are taking place satisfactorily.

[redBeard]

Task Manager is worthless for real-time CPU monitoring.

Yeah, that's what I figgered....

Also, CPU usage is a tricky metric. Is there an actual performance problem in your application? If not, measuring CPU activity isn't going to tell you much; it's generally reported as some sort of average over a time interval, so if the interval is long enough the percentage will drop, while if the interval is made too short it will report 100% activity. top can be extremely misleading in this regard.

Unless your program is utilizing 100% of the CPU for extended periods of time, I wouldn't pay any attention to this metric, particularly if the UI is responsive and updates are taking place satisfactorily.

Is there a problem? Well, my end application will probably have 10 - 20 instrument displays, some using basic QPainter primitives and some using OpenGL primitives. I was sort of shocked to see 50% utilization with only 3 simple instruments and no real other processing (my prototype does no DSP work - filtering, FFTs, etc. - just displaying raw signal data).

I was concerned that what I am doing will not scale well.

I have seen other applications like I'm writing with 10-20 display instruments and fairly extensive (50 or so) data transform elements take 1 - 2 % CPU. Impressive...

[wysota]

I will say what I'm usually saying in such cases. Do you really need to update 30 times per second? Plotting real-time data doesn't mean that plotting has to be real-time as well. Your eye won't manage to register any details of the plot at such frequency. Try dropping the framerate to 20Hz or even 16Hz and you should be fine. You can also have an adaptive timer that will increase frequency when more CPU power is available and reduce it when the load rises. This should make your app scale well for a different number of data sources.

Also consider setting some flags for your widget, you should be able to optimize things a bit more.

[redBeard]

I will say what I'm usually saying in such cases. Do you really need to update 30 times per second? Plotting real-time data doesn't mean that plotting has to be real-time as well. Your eye won't manage to register any details of the plot at such frequency. Try dropping the framerate to 20Hz or even 16Hz and you should be fine.

You are correct here. We have tuned the refresh rate accordingly. I do have one instrument display, however, that is rather choppy looking at 16 - 20 frames/sec. It looks best at 25 - 30 frames/sec.

You can also have an adaptive timer that will increase frequency when more CPU power is available and reduce it when the load rises. This should make your app scale well for a different number of data sources.

I like that idea a lot.

Also consider setting some flags for your widget, you should be able to optimize things a bit more.

QWidget flags? Which ones?

I also found another CPU hog with my display code, as well. I have a nice looking linear gradient for background of the main instrument panel, using QLinearGradient, the parameters of which are set in the central widget resize() method. That's what our screen designer wanted.....

I found that no background reduced the CPU utilization dramatically - to about 10% on Linux when the overall instrument panel was maximized to full screen. That appears to be approaching QTimer overhead of the two timers I have. I'll see if i can use a static image instead for this and position it in the background according to the size of the overall instrument panel.

[wysota]

You are correct here. We have tuned the refresh rate accordingly. I do have one instrument display, however, that is rather choppy looking at 16 - 20 frames/sec. It looks best at 25 - 30 frames/sec.

Are you reconstructing the path from scratch at every update?

QWidget flags? Which ones?

For example Qt::WA_OpaquePaintEvent and Qt::WA_StaticContents

I also found another CPU hog with my display code, as well. I have a nice looking linear gradient for background of the main instrument panel, using QLinearGradient, the parameters of which are set in the central widget resize() method. That's what our screen designer wanted.....

I found that no background reduced the CPU utilization dramatically - to about 10% on Linux when the overall instrument panel was maximized to full screen. That appears to be approaching QTimer overhead of the two timers I have. I'll see if i can use a static image instead for this and position it in the background according to the size of the overall instrument panel.

Cache the background.

[redBeard]

Are you reconstructing the path from scratch at every update?

No. For the oscilloscope-type displays I have a QPainterPath of the range n domain axis lines which is only calculated when the display size changes. The actual data lines are an array of QLines. This is filled as the data arrives from an upstream flow element. The paintEvent() method just draws the one QPainterPath of axis lines and the drawLines() of the lines array (and, of course, setting the correct pen color).

The jumpy display in question is an OpenGL-based graphic displaying FFT data (e.g., frequency analyzer). The vertices data never changes from refresh to refresh, just the colors. So I build the vertices buffer when the screen size changes. I cache the collection of color vectors and only recalculate the colors for new data when it arrives and 'memcopy' the old data to the new locations.

Each refresh just consists of a single OpenGL call (glDrawElements()).

For example Qt::WA_OpaquePaintEvent and Qt::WA_StaticContents

I'll look at those.

Cache the background.

Here's the code for the background linear gradient:

centralWidgetConstructor() {
        QLinearGradient backgroundGradient;
        backgroundGradient.setStart(), setFinalStop(), setColor()......
 
	setBackgroundRole (QPalette::Window);
	QPalette p (palette());
	p.setBrush (QPalette::Window, QBrush (backgroundGradient));
	setPalette(p);
}
centralWidget::resize() {
	backgroundGradient.setFinalStop(width()/2, 0);
	QPalette p (palette());
	p.setBrush (QPalette::Window, QBrush (backgroundGradient));
	setPalette(p);
}

centralWidgetConstructor() {
        QLinearGradient backgroundGradient;
        backgroundGradient.setStart(), setFinalStop(), setColor()......

	setBackgroundRole (QPalette::Window);
	QPalette p (palette());
	p.setBrush (QPalette::Window, QBrush (backgroundGradient));
	setPalette(p);
}
centralWidget::resize() {
	backgroundGradient.setFinalStop(width()/2, 0);
	QPalette p (palette());
	p.setBrush (QPalette::Window, QBrush (backgroundGradient));
	setPalette(p);
}

To copy to clipboard, switch view to plain text mode 

The QLinearGradient is calculated when the screen size changes (which is not very often, typically when the display is first rendered. Users only rarely change the panel size).

[wysota]

No. For the oscilloscope-type displays I have a QPainterPath of the range n domain axis lines which is only calculated when the display size changes. The actual data lines are an array of QLines. This is filled as the data arrives from an upstream flow element. The paintEvent() method just draws the one QPainterPath of axis lines and the drawLines() of the lines array (and, of course, setting the correct pen color).

Can you show us some code? I can immediately suggest an optimisation - if you append data to the path then you can cache parts of the path as pixmaps and only append the new chunks to the pixmap(s). Then drawing the plot boils down to rendering one or more pixmaps.

The QLinearGradient is calculated when the screen size changes (which is not very often, typically when the display is first rendered. Users only rarely change the panel size).

This doesn't do any graphics calculations or even colour calculations for the gradient. QLinearGradient is strictly a data carrier, nothing more. Your gradient is recalculated and redrawn upon every paint event. It's much better to render it once to a pixmap and then just blit the pixmap to the widget (with opaque paint event attribute set). In the end of all optimisations your paint event should be reduced to drawing at most three layers of pixmaps - the background, the plot and the foreground (grid). If you can combine the background and the foreground and draw the plot over the foreground, that's even better. Notice that with a GL paint engine this will be done by blitting three textures directly from the card's memory so it should be very fast.

[SixDegrees]

Yeah, that's what I figgered....


Is there a problem? Well, my end application will probably have 10 - 20 instrument displays, some using basic QPainter primitives and some using OpenGL primitives. I was sort of shocked to see 50% utilization with only 3 simple instruments and no real other processing (my prototype does no DSP work - filtering, FFTs, etc. - just displaying raw signal data).

I was concerned that what I am doing will not scale well.

I have seen other applications like I'm writing with 10-20 display instruments and fairly extensive (50 or so) data transform elements take 1 - 2 % CPU. Impressive...

Don't you think there's something wrong if your computer is only using the CPU 2% of the time?

In real life, the CPU is working at 100% capacity very nearly 100% of the time. How that usage is allocated to a particular program, over a particular period of time, varies so widely as to be meaningless.

I'm usually much more concerned that a program is running correctly when it is initially developed; if needed, optimization can be applied later at the points where it is required.

[redBeard]

I'm usually much more concerned that a program is running correctly when it is initially developed; if needed, optimization can be applied later at the points where it is required.

Obviously correctness is paramount. I only optimize after verifying correctness of the software.

However, I have a large number of elements to develop, creating a good pattern now whilst in prototyping stage will allow me to develop these elements without having to go back (much) and optimize a large code base.