compatibility problem with a waterfall display

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

Quote:

---

Originally Posted by janK

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

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

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