Before starting to copy code it might be worth to spend some time with basic thoughts:

1) Painting is a slow operation ( compared with recording) - maybe too slow to be done in a recording cycle. To avoid, that you miss recording cycles or your user interface becomes unresponsive you should always decouple sampling and refresh rates. ( f.e. your proposed design might flood the event queue followed by hanging updates and an unresponsive GUI ).

So I strongly recommend to implement the following design:

a) A sampling thread that does nothing beside recording and storing samples
b) The user interface periodically updates itsself according to the stored samples

2) Even if the painting performance doesn't affect the recording anymore you might want to see at least a minimum refresh rate.

The first thing you should do is to start the refreshtest example to see how many replots per second you can do for a curve with a number of points, that is comparable to your situation. If you are happy with this rate simply call replot() periodically.

Only if the rate is too low you have to find a strategy to improve the painting performance. The most obvious way is to reduce what needs to be painted. F.e you could reduce the number of points using QwtWeedingCurveFitter ( = Douglas Peucker ). Another option is to paint only new points ( this is what the oscilloscope example does and what QwtPlotDirectPainter is about).

Note, that the design of your application has an important impact on what is possible or not. F.e. the bottom scale of the oscilloscope example is incremented in fixed time intervals only. Only this way it is possible to paint incrementally. In opposite the cpuplot example always shows the last minute, what requires a full repaint for each update.

Uwe