Quote Originally Posted by redBeard View Post
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.