QwtPlotCurve draw it's full contents without using current zoom information

[mike_the_tv]

Store the rectangle and use it in your implementation of:

• virtual size_t AnalogPlotData::size() const;
• virtual QPointF AnalogPlotData::sample( size_t i ) const;

OK, I think I understand now. The AnalogPlotData would store its actual size as well as the rectangle of interest size. When the ROI is smaller, return that value for size() and for sample() return an offset subset of the data based on where the ROI is in the whole data vector, i.e. if the total size is m and the ROI in the x axis is x to x+n, size() would return n and sample(0), (1), (2), ... would return actual data values data[x], data[x+1], data[x+2], ... instead of data[0], data[1], data[2], .... I can then see that the plot routines would lookup the smaller ROI size() to calculate the from/to values and the sample() function would only return data from the ROI.

I would have to modify some of my existing code and add one or two members to the AnalogPlotData class to return the actual data size and the complete sample data as other parts of my code rely on knowing the real total number of samples and being able to access the whole data array, for example to compute an FFT, etc.

With Qwt 6.0 setRectOfInterest() is always called - with trunk it is called depending on the flag.


Depends on your requirements, but the version in trunk is probably the version with the most new features ever. For curves you find a couple of performance optimizations and when you are not on X11 ( here you have hardware acceleration ) you might be interested in checking the experimental OpenGL canvas.

Are any of the performance improvements likely to benefit Windows?

Douglas Peucker is an expensive operation - better don't assign it as fitter to the curve.

Just to see how the curve fitter class worked I did try attaching this directly and it was indeed very slow.

Instead I recommend to build a couple of series with different tolerances ( maybe about 5 ) in advance ( using QwtWeedingCurveFitter directly ) and store them in your data class. Then activate one of them according to setRectOfInterest(). Together with clipping ( fast operation ) this should be what you are looking for.

The only thing that puts me off using this is the time needed to compute the pyramid of scales prior to displaying the data. As the data sets could be very large (I just calculated the theoretical limit of samples returned by our hardware and it was in excess of 256,000,000, 32bit samples) the time taken to initially plot the data, even if I backgrounded calculation of other pyramid scale levels, would be too large. Once calculated the redraw would indeed be very fast as it would be all cached.

I now have a rough implementation of my min/max of all samples represented by one plot pixel and this works very well even when calculated on each redraw and for all data samples. Once you get multiple line plotted for sub-pixel samples, all you really see if the waveform envelope anyway.

What would be really good would be to push this weeding of sample points back into the AnalogPlotData class as this would eliminate the need for weeding a large data set down before plotting and also reduce the memory requirements of the application as the QPolygonF vector constructed in drawLines() from the sample() data would not need to be as big as the data set (x2 as its x and y coordinates), but only as big as the weeded data set (x2). With the potential number of samples I need to support, the amount of host memory used in storing the actual data and any temp copies is getting quite significant. To do this I would need to know the plot canvas size and also get updates when this changes.

I always wanted to implement a small demo showing how to implement different levels of detail for a huge curve. When you offer me a generator for curve points that make sense for such a demo you would find a working implementation in SVN.

Uwe

If I come up with something simple I will pass it on.