QwtPolar surface Plot performance zooming

[john_k]

Hi I have a program that I am working on that uses QwtPolarPlot to plot a QwtPolarSpectrogram and it is working great but when I zoom in with the scroll wheel after a short while the performance starts to bog down. Is there any performance tuning on the zoom that I could do to help this?

Thanks for the hard work guys.

[Uwe]

What about the polar spectrogram example - do you see any performance issue when zooming in there ?

In general: with QPainter you have the effect, that it renders before it clips. For a spectrogram this is of no importance, but any type of vector graphics this might become an issue when zoom in in deep.
Should be no issue with standard Qwt plot items as they do clipping before calling QPainter methods ( check f.e QwtPolarGrid::ClipGridLines ). So it might be worth to test your application without any other plot item beside the spectrogram.

If you still see performance issues it could be a problem of your raster data implementation ( or do you use QwtMatrixRasterData ? ), but you would have to show some code then ?

Uwe

[john_k]

Hi Uwe.

The spectrogram demo works fine.
In our implementation of the zoom starts to slow down significantly after four to five rolls of the mouse wheel.
We are using QwtMatrixRasterData.
Is the a setting in QwtPolar like QwtPlot for a max zoom stop?
I tried the ClipGridLines option but it made no difference.
We have very few other items on the plot besides the spectrogram and grid but I will check that and see if it makes a difference.

[john_k]

QwtPlotZoomer has setMaxStackDepth does QwtPolar have a similar function that can be used with the QwtPolarMagnifier to set a maximum zoom?

I counted the number of clicks on the mouse for zooming and it was around 30 when the zooming started to bog down.

[Uwe]

There has to be a reason why your plot slows down and it should be possible to find it out !

a) What happens, when using SpectrogramData of the spectrogram example in your application - instead of your data class ?
b) If you have a small demo showing the issue, I will have a look at it

Uwe

[john_k]

Here is an example.

[Uwe]

Reason for the performance issue can be found in QwtPolarSpectrogram::draw.

Here the spectrogram calculates a clip region for the bounding circle of the data. When you zoom in deep the circle gets huge and calculating the region ( = approximation of the circle by a list of rects ) becomes very expensive.
The difference between the spectrogram example and your demo is simply, that in the spectrogram example the range of the data is unlimited and therefore no clipping needs to be done.

For your use case you could simply remove the "if ( radialInterval.isValid() ) ... " block, as QwtMatrixRasterData returns NaN for out of bound requests, what gets mapped to a transparent RGB value.
Unfortunately this doesn't work for Indexed8 colors as there is no transparent color in the color table ( NaN is mapped to the first color ).

For the moment I added a quick fix to filter out situations, where you don't need the clip, because the canvas is completely inside of the data circle. But when you zoom in deep at the border of the data circle ( cutting the canvas ) I need a better fix - hope QwtClipper will help me here too.

Uwe

[Uwe]

Guess I found a better one using clip paths instead of clip regions, what avoids any issues with huge rectangle lists.

Fixed in SVN,
Uwe

---

Added after 4 minutes:

Here is an example.

One comment about RasterData::setXInterval() in your demo: here you are excluding 2 * M_PI, but including 0.0.
In certain zoom levels 2 * M_PI happens leading to a vertical line with missing RGB values. I would recommend to allow 2 * M_PI instead:

setInterval( Qt::XAxis, QwtInterval( 0, 2 * M_PI ), QwtInterval::IncludeBorders );

setInterval( Qt::XAxis, QwtInterval( 0, 2 * M_PI ), QwtInterval::IncludeBorders );

To copy to clipboard, switch view to plain text mode 

Uwe

[john_k]

Thanks Uwe.

Right now we are running qwtpolar-1.1.0 that we downloaded the source from from http://qwtpolar.sourceforge.net/ is there a way to get just the fix we are talking about here or do we have to take all the fixes that are in SVN? (never used SVN so not to sure of the procedure)

Thanks again Uwe for your hard work.

[john_k]

Found the code at http://sourceforge.net/p/qwtpolar/code/181/ , compiled it and it works