Qwt zooming is *SLOW*

Here are the tests which I did:

Test #1: Generate 1000'000 point data. Plot it with widget based on old QwtPlotGLCanvas class, using current Qwt ver. 6.1.3

Result: Terribly slow. Unusable zooming at all. Takes few seconds for every several pixels of dragging the mouse tracker to settle, and same few seconds to perform the zoom. On top of that a lot of glitching/blinking of tracking borders and tracking font. Totally unusable.


Test #2: Use SVN version 6.2.0, same 1000'000 point generated plot. Use the new QwtPlotOpenGLCanvas class.

Result: Slow. Still takes 6-8 seconds to actually zoom after the tracking zooming border is un-clicked. No tracking border or font glitching though. Still close to unusable.


Test #3: Same as Test #2, but also add the FilterPointsAggressive property to the curve.

Result: I notice some speedup, but it still takes this time few seconds to perform zoom after setting the tracking border. Still hardly usable.


Test #4: Use SVN version 6.2.0, same 1000'000 point generated plot. But just use regular QwtPlotCanvas, no messing with OpenGL.

Result: Results are kinda close to results of Test #3, maybe a second faster. but still slow.

Test #5: Use SVN Version 6.2.0, same 1000'000 point generated plot. Use regular QwtPlotCanvas class for canvas, again no OpenGL. But, add the FilterPointsAggressive property to the curve.

Result: OK, Now I have "something usable", this time delay is like 1-1.5s between un-clicking the zoom tracking cursor and actually graph being replotted properly with new zoom.


Now I can see that it just does not even make sense to use OpenGL here for this specific application, i.e. generating some big data, and then working with it by looking/zooming at different parts of it here and there using the zoom functionality.

And even if you forget about OpenGL... The Qwt is itself *SLOW* for the typical applications described above, i.e. when you for example model something, and your algorithms generate some plot in memory and now you need to peek at it carefully and often at its different parts, etc.

P.S. just for laughs I asked someone to perform similar experiment, i.e. generating 1000'000 points in some program called NI LabView, and to my surprise it just smoke my results obtained from Test #5! It was super fast and immediate response there to zoom in at different parts of the generated plot....

I just do not feel that Qwt is much of a use for these specific type of applications, unless the data amount is not big, or 1-2 second delay is OK for someone. I think it is still OK as a small auxiliary tool for quick modeling/showing data in Qt GUI applications, but nothing bigger than that.

And regarding OpenGL...I just feel that the whole "support" of OpenGL is executed poorly. Although this specific application used during these tests was not intended specifically to test the OpenGL speed of Qwt. (Print/PDF functionality is a horrible reason to use those combination of underlying classes and degrading speed/performance)

First of all: zooming is the process of selecting ranges on the scale + repainting. So when talking about performance it is always a matter of how long does it take to render a scene. A good way to measure the performance is to add QElapsedTimer in QwtPlot::drawCanvas ( when talking about SVN trunk ) and resize the main window.

But in your case I have zero information about what and how you are rendering - beside, that it somehow related to 1000000 points. F.e the scatterplot example handles 1000000 points in 15-30ms ( depending on the canvas size ), but this is a totally different thing compared to a line plot of 1000000 points in random order painted with a pen width > 1, maybe even antialiased + using non trivial symbols.

Concerning the bottlenecks: I would expect, that almost all of the time gets lost in QPainter::drawPolyline - regardless if you are using OpenGL or raster. Drawing 1000000 lines is expensive, when using a Qt paint engine and no QPainter based plot package can change this. But what can be done is to filter out unnecessary lines, before passing them to QPainter and this is the part where you can compare implementations ( f.e try the official Qt chart module ).

You wrote, that your use case, is an oscilloscope alike plot. Typical here is, that points are ordered in x or y direction. When your test data matches this criterion the FilterPointsAggressive will reduce the number of lines to a maximum of 3 * width ( or height ) of the visible canvas. I don't see why rendering them would take > 1 second.

But another typical aspect of an oscilloscope is, that it displays curves in a high frequency maybe 20 times a second. Something I would expect hard to achieve, when having fresh 1000000 points every 50ms ( or even faster ).

But anyway - if you have a small compilable demo I can have a look at it.

Uwe

PS: A word on your aggressive tone: come on !

Uwe, I have 2 applications, one which I plan to use for real time scope, another for non-real time plotting of data generated in memory. In this thread I am talking about example where I generate data in memory and then plot all of it.

OK, here is what I did:

1) Reduce Pen to 1
2) remove Symbol plotting completely (no Symbols added to curve)

Now it is much faster, I'd say quicker than 1 second. So now it is Doable.

HOWEVER! I am using simple canvas! Not OpenGL Canvas! Once I turn the OpenGL canvas it becomes slow again (!) even with the above changes! Any ideas why turning the OpenGL Canvas would make it WORSE than regular canvas? (it doesnt matter OpenGL canvas from SVN or regular version based on old opengl widget)

THe compilable source example is attached, it is zipped Qt project folder. There in widget.cpp if you uncomment line #32 and comment line #33 things become slower...

Quote:

---

Originally Posted by Uwe

your aggressive tone

---

Which exactly line/sentence from my original message contains anything agressive?

Quote:

---

Originally Posted by r2com

In this thread I am talking about example where I generate data in memory and then plot all of it.

---

This is a totally different situation, than an oscilloscope as you could do some preprocessing - creating different level of details - outside the render loop in advance.

But anyway: I stripped down your demo to the relevant code and replaced the QwtSyntheticPointData by calculating the points in advance ( qSin is an expensive operation and doing it 1000000 times in the render cycle is more expensive than rendering itself ). I also modified the y ranges as with your settings lines will be short only - not challenging the render engine enough.

Code:

---

#include <QApplication>
#include <QElapsedTimer>
#include <qwt_plot.h>
#include <qwt_plot_curve.h>
#include <qwt_plot_canvas.h>
 
class MyPlot: public QwtPlot
{
public:
    MyPlot()
    {
        const int numPoints = 1000000;
 
        QwtPlotCanvas* canvas = new QwtPlotCanvas();
#if 0
        canvas->setPaintAttribute( QwtPlotCanvas::OpenGLBuffer, true );
#endif
        setCanvas( canvas );
        setCanvasBackground( Qt::white );
        setAxisScale( QwtPlot::yLeft, -1.5, 1.5 );
        setAxisScale( QwtPlot::xBottom, 0.0, numPoints );
 
        QwtPlotCurve *curve = new QwtPlotCurve();
        curve->setTitle( "Some Points" );
        curve->setPaintAttribute(QwtPlotCurve::FilterPointsAggressive, true);
 
        QPolygonF points;
        for ( int i = 0; i < numPoints; i++ )
            points += QPointF( i, qSin( i ) );
 
        curve->setSamples( points );
        curve->attach( this );
    }
 
    virtual void drawCanvas( QPainter *painter )
    {
        QElapsedTimer timer;
        timer.start();
 
        QwtPlot::drawCanvas( painter );
 
        qDebug() << size() << timer.elapsed();
    }
};
 
int main( int argc, char **argv )
{
    QApplication a( argc, argv );
 
    MyPlot plot;
 
    plot.resize( 600, 400 );
    plot.show();
 
    return a.exec();
}

---

Now running this code on my system ( Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz, 4988.50 + onboard graphics ) - something middle class - I have the following output:

Quote:

---

QSize(1920, 1132) 65

---

When enabling QwtPlotCanvas::OpenGLBuffer - this is a mode, where the plot is rendered to a FBO translating it to a QImage later - I have the following:

Quote:

---

QSize(1920, 1132) 19

---

I also tried Qt4 with the X11 paint engine:

Quote:

---

QSize(1920, 1132) 41

---

Finally I tried QwtPlotOpenGLCanvas:

Quote:

---

QSize(1920, 1132) 32

---

Having a range of 19ms to 65ms for 1000000 doesn't sound totally bad to me.

O.k. doing the tests 1,2 and 4 without FilterPointsAggressive:

Quote:

---

QSize(1920, 1132) 1764
QSize(1920, 1132) 64
QSize(1920, 1132) 99

---

The first value is of course totally bad, but pumping in 1000000 points to the raster paint engine is something it can't handle with good performance. The OpenGL values look o.k.

Sorry, but I don't understand your initial complaints - to me it looks like the FilterPointsAggressive mode does a pretty good job - especially in combination with QwtPlotCanvas::OpenGLBuffer, where you don't have any of the problems of the OpenGL based canvases.

Uwe

I compiled your example AS IS, and had the following result right away:

Quote:

---

QSize(600, 400) 137

---

Which is OK, but then I did the following thing:

change line #14 containing this code:

Code:

---

QwtPlotCanvas* canvas = new QwtPlotCanvas();

---

to this code:

Code:

---

QwtPlotOpenGLCanvas *canvas = new QwtPlotOpenGLCanvas(); // NEW OpenGL Canvas

---

And I got this printed in console:

Quote:

---

QSize(600, 400) 254
QSize(600, 400) 144
QSize(600, 400) 131

---

Any idea why it got printed (drawCanvas) got called 3 times? And why numbers for me turn out to be worse if I am using QwtPlotOpenGLCanvas ?

Again, I did not touch anything in your provided code, as I said, first ran it as you provided, and then just changed that line of code.

So why in this case using QwtPlotOpenGLCanvas makes it slower?

Another series of tests - now measuring the time of QwtPlotCanvas::paintEvent and QwtPlotOpenGLCanvas::paintGL:

Quote:

---

QwtPlotCanvas: 70ms
QwtPlotCanvas with OpenGLBuffer: 80 ms
QwtPlotOpenGLCanvas: 42 ms

---

Now QwtPlotOpenGLCanvas is the fastest mode - what makes sense as the FBO to QImage translation is an expensive ( but not depending on the plot scene ) operation.

Finally:

Quote:

---

QwtPlotOpenGLCanvas without QwtPlotOpenGLCanvas::BackingStore: 34 ms

---

As QOpenGLWidget has its own FBO there is not much sense in having another backing store in QwtPlotOpenGLCanvas ( triple buffering ). Guess all in all this is the fastest combination when putting everything together.

One comment on zooming: using QwtPlotMagnifier does not make much sense with heavy plots. The problem is, that you trigger several paint event, that can't follow the mouse wheel events. Better stay with QwtPlotZoomer, where you don't have the effect of cumulating delays.

Also have a look at QwtWeedingCurveFitter. It is a heavy algo ( even when using small chunk sizes ~20 ), that can't be used inside the plot cycle. But it can be used to create different levels of details at startup and switch between the different sets according to the zoom ranges. Then you will have a small set of points when displaying the complete curve, while you can use the complete number of points, when zooming in deep, as the polygon clipping algo will be successful then.

Quote:

---

Any idea why it got printed (drawCanvas) got called 3 times?

---

I have the same issue - this seems to be a problem of QwtPlotOpenGLCanvas. But as written in my initial posting: the implementation of this class is not done. It is in trunk and not yet part of the stable branches for reasons.

Quote:

---

And why numbers for me turn out to be worse if I am using QwtPlotOpenGLCanvas ?

---

I don't know: OpenGL is an API - not an implementation. On my box ( Linux ) it is faster, maybe implementation on your box falls back to some software renderer. To me it looks like this as ( beside of the first frame, that might have some initializations ) the frames seem to have exactly the same performance as the raster paint engine.

Better do some benchmarking using native OpenGL applications to find out.

Uwe

Quote:

---

Originally Posted by r2com

Any idea why it got printed (drawCanvas) got called 3 times?

---

I has some time to check this issue - it has to do with the Qt framework being less smart for both types of OpenGL widgets.

In case of QOpenGLWidget it sends paint events before the initial QEvent::PolishRequest. As PolishRequest is always followed by another Paint event it can be blocked on Qwt side easily ( done in SVN trunk ). The first paint event is of that category.

The second one depends on activation of the main window, what leads to a repaint in case of the canvas having the focus ( focus indication needs to be done ). It can be avoided by not having the focus initially on the canvas, but when having the canvas backing store enabled ( default setting ) this is a cheap repaint taking 0ms.

In case of QGLWidget the situation is more difficult as several Paint events just happen ( f.e on Window activation - with or without focus on the canvas ). As QGLWidget does not have an internal FBO ( another backingstore ) there are more situations, that need to be solved by calling the derived class for repaints. But again those are no problem when having the canvas backing store enabled.

The only repaint that did hurt before was the one, that happened before the PolishRequest, as it happened before the canvas had its initial size. But when having the backing store disabled you might of course run into several potentially repaints depending on user interactions ( enter/leave with the mouse ). In this case it will be better to fill in the curve after the canvas is already on screen.

Uwe

OK so here is what I have done, put resize(500,500) and show() functions right after I set the canvas. And then create my curve, grid and scale and attach to plot.

It again got called 3 times, but with following printout:

Quote:

---

QSize(500, 500) 0
QSize(500, 500) 142
QSize(500, 500) 139

---

What else am I supposed to do? Did I miss something?

Or you did some very latest changes to SVN trunk and I need to compile SVN trunk code again?

Quote:

---

Originally Posted by r2com

Or you did some very latest changes to SVN trunk and I need to compile SVN trunk code again?

---

Yes, from today.

Uwe

OK, now I see it worked, and it is called only once, my result is around 130ms for new OpenGL Canvas, but same for the old simple canvas... I'll test it on my gaming rig at home with GTX 980 to see what will be the difference there.