compatibility problem with a waterfall display

[janK]

Hello all

My application is software defined radio, with relatively easy gui issues. I have been using qwt 5.2 for generating spectrum displays and
waterfalls, the latter showing the evolution of the spectra with pretty good results.

I have been managing getting the spectrum displays using qwt 6.xx, however, it seems that having the waterfalls using 6.xx
requires some additional rewriting and brings me a severe performance loss.

The waterfall itself is implemented as a spectrogram, using n * 256 * 50 elements (n is user selectable, I am just keeping 50 lines of spectral info in the
waterfall). My approach was to have a large vector of doubles using as qwtrasterdata.
With a simple vector, it is possible to use highly optimized transfer functions. Each time a new line appears to be displayed,
I just move (with memcopy like and memove functions) all data one line (i.e. it will be shifted over n * 256 doubles), add then the data for the new line and replot.
The vector was part of a class spectrogramdata, an extension of qwtrasterdata, with (a.o) a function value implemented.

This does not work in 6.xx

When forced to use a class qwtmatrixrasterdata, the data will be stored in a vector<double>, and I am apparently loosing the possibility
of using optimized memory transfer functions. I am generating between 10 to 15 per second a new waterfall frame, and it goes up to
3 waterfalls on the screen, so efficient dealing with this data is a real must.

My question: is my attempt to keep a simple implementation of my own extension of qwtrasterdata with my own value function doomed to fail
or am I just making programming errors, keeping it away from working?

Any help is appreciated,
all the best
jan

[Uwe]

When forced to use a class qwtmatrixrasterdata ...

QwtMatrixRasterData is for certain situations easier to use, but obviously not in your case. What makes you believe that you are supposed to use it in Qwt 6.0 ?

The difference of QwtRasterData between 5.2 and 6.0 is ( beside trivial renaming ) that you have to return the bounding intervals of the axes by interval(Qt::Axis ) instead of boundingRect() + range(). Also the copy method is gone - instead the pointer to the data object is passed to the spectrogram item taking ownership. Porting your derived class should be a job of 5 minutes.

Performancewise Qwt 6.0 should be significantly faster on multicore systems as you can tell the spectrogram to divide the image into tiles rendering them in different threads ( spectrogram->setRenderThreadCount( 0 ); ) ).

HTH,
Uwe

[janK]

Well, the (my) problem seems to be that whatever I try, there is a crash of the program (segmentation violation) in pixelhint and I do not seem to be able to tell the
qwtrasterdata what the actual data is (a value function is implemented).

>>> instead the pointer to the data object is passed to the spectrogram item taking ownership.<<<< ??????

It might have been solved in 5 minutes by someone understanding the modifications, it takes now three days

best
jan

[Uwe]

Hm, what needs to be done:

• Call YourRasterData::setInterval
  The intervals for the x/y axes are the values you have passed with setBoundingRect before. The interval for z axis is what you have returned as range before.
• Implement the YourRasterData::value method
  Absulutely nothing has changed here.
• Optionally implement YourRasterData::pixelHint(). pixelHint() returns not only the size of a pixel ( rasterHint() returned the number of pixels ! ) but also a position, so that the image can be aligned properly. You can return the geometry of any pixel.
  Note that the pixelHint is not working in Qwt 6.0.1 - you need to use the code from SVN 6.0, or wait for 6.0.2 what will happen the next days.

Then do: spectrogram->setData( new YourRasterData() );

The previous data object gets deleted, when you pass a new data object, but in your case I guess YourRasterData is somehow connected to your vector of doubles and you directly modify this vector behind the back of the spectrogram item. Beside this vector I guess you need to adjust the interval of the y interval and to invalidate the cache ( if QwtPlotRasterItem::PaintCache is enabled ) before you call replot. But this is not different to what you had to do with Qt 5.2.

Uwe