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

[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.