QwtPlot::replot() won't clear current plot

[Mindstormer]

Hm, your code uses the direct painter in the same cycle as the replot - there was a bug report indicating that the paint region of the replot gets swallowed by the internal pain event generated by the direct painter. Maybe this is the case in your application too ( don't see any obvious bug ). I would be interested in investigating in this issue - could you please upload a small compilable demo ?

For your type of application I would recommend to go with Qt4 ( not Qt5 ) enabling the X11 paintengine ( graphicssystem: native ). Only this way you might see hardware accelerated graphics and the direct painter is more effective as it doesn't need to send dummy paint events ( what probable are the reason for the issue above ).

Then initialize your canvas this way:

QwtPlotCanvas *canvas = new QwtPlotCanvas();
canvas->setPaintAttribute( QwtPlotCanvas::BackingStore, false );
canvas->setAttribute( Qt::WA_PaintOutsidePaintEvent, true );
 
plot->setCanvas( canvas );

QwtPlotCanvas *canvas = new QwtPlotCanvas();
canvas->setPaintAttribute( QwtPlotCanvas::BackingStore, false );
canvas->setAttribute( Qt::WA_PaintOutsidePaintEvent, true );

plot->setCanvas( canvas );

To copy to clipboard, switch view to plain text mode 

You could also play with:

canvas->setAttribute( Qt::WA_PaintOnScreen, true );
canvas->setAttribute( Qt::WA_NoSystemBackground, true );

canvas->setAttribute( Qt::WA_PaintOnScreen, true );
canvas->setAttribute( Qt::WA_NoSystemBackground, true );

To copy to clipboard, switch view to plain text mode 

Uwe

Hi!

I dont really know what the advantage and the disadvantages is between Qt4 and Qt5 but it took me a good while to get Qt5 up and running on the RPI so I would prefer to avoid all that hazzle again. The thing that confuses me is that I have got the qwt realtime and qwt oscilloscope example up and running and they work flawlessly. And they do pretty much what I want to do, however, those example are able to replot so it leads me to think that somewhere in my code there is an error.

I have attached a compilable example to this post, the only difference between the example and the project I attached in the OP is that random numbers are generated instead of reading values from a file, the file was to big to be attached if I used the original project.

qwtTest.zip

Also tested the suggestions you had in your reply but it didn't work.

And lastly, please note that I cross compile the project to my RPI so you may have to change the project file.

Best regards!

[Mindstormer]

A small update, I somehow got the clearPlot() method to work but I don't know if I've solved it in an "incorrect way".

I changed my clearPlot() method to the following:

void Plot::ClearPlot()
{
    CurveData *data = static_cast<CurveData *>(d_curve->data());
    data->clear();
 
    QwtPlot::replot();
    QwtPlot::repaint();
}

void Plot::ClearPlot()
{
    CurveData *data = static_cast<CurveData *>(d_curve->data());
    data->clear();

    QwtPlot::replot();
    QwtPlot::repaint();
}

To copy to clipboard, switch view to plain text mode 

I have to call replot and then I have to call repaint as well. Does anyone know why it works when I do it like this?

[Uwe]

I dont really know what the advantage and the disadvantages is between Qt4 and Qt5 but it took me a good while to get Qt5 up and running on the RPI so I would prefer to avoid all that hazzle again.

Sure but as you are on a Pi where you have a very weak CPU and your question is about performance it is worth to understand your options:

There are to paint engines available for Qt/X11:

• raster
• x11

The raster paint engine is a pure software renderer, what means the lines of a curve are calculated pixel by pixel by the CPU. The X11 paintengine is using the Xlib for rendering lines, what would be done by the graphics hardware, when you have X11 drivers on your system, that support hardware acceleration. Qt4 offers both paint engines and you can decide which one to use. For Qt <= 4.7 X11 is the default, but for Qt4.8 raster has been made the default. In Qt5 only the raster paint engine is available.

But even, when going with raster you should disable the backing store of the canvas for something like a oscilloscope. It doubles what the software renderer has to do, while you never use widget overlays on the canvas ( f.e the rubberband of the zoomer ), where the backing store is of interest.

I remember running the oscilloscope example on the Pi at about 20% CPU load.

The thing that confuses me is that I have got the qwt realtime and qwt oscilloscope example up and running and they work flawlessly. And they do pretty much what I want to do, however, those example are able to replot so it leads me to think that somewhere in my code there is an error.

No this should be the Qwt issue I was talking about in my previous mail. You can avoid it by setting QwtPlotCanvas::ImmediatePaint to true, what has the effect, that the replot calls repaint instead of update.

Uwe

[Mindstormer]

Thanks for your help Uwe, much apreciated!

I remember running the oscilloscope example on the Pi at about 20% CPU load.

Which QT version was that? I just checked my CPU usage on my pi and it was 20-25% with QT5.

[Uwe]

Not 100% sure but AFAIR it was an earlier Version of Raspbian running Qwt 6.1 with Qt4 ( using X11 paint engine ). But when using X11 much of the work is done in the X Server what needs to be taken into count, when comparing systems.

I recommend simply to install Qt4 on your system and build Qwt for it ( maybe there are precompiled packages available ? ) . Then you can compare the oscilloscope example running it with raster or x11: see .http://qt-project.org/doc/qt-4.8/qap...GraphicsSystem