Spectrogram too slow

[a_kaa]

I'm trying to create a spectrogram out of audio data using QwtRasterData and QwtPlotSpectrogram. This works, but it is too slow. I played a little with rasterHint(), but if I make it fast enough, the result looks horribly grainy.
My spectrogram is about 1000x400px in size and the value() method uses bilinear interpolation.
I think the problem must be in the many calls to value() - all my other operations don't take this long, but it still takes ages even when I don't do much in value(). I'm doing all of this in Python and my data is stored in dictionaries (but I don't think that makes a difference since it's still slow when I'm not even using them).
Any ideas on improving the speed? Alternatively, could I render the spectrogram in a separate thread?

[Uwe]

My spectrogram is about 1000x400px in size and the value() method uses bilinear interpolation. I think the problem must be in the many calls to value() ...

1000x400 pixels mean 1000x400 calls of value() !

... but it still takes ages even when I don't do much in value().

Maybe your CPU has a different opinion about what "much" is ?

Have a look at the spectrogram example ( from Qwt not pyqwt !) - is it fast enough on your system ? If yes translate the implementation of its value method to python and use it in your application. If this is also fast enough your code in value() makes the difference.

Any ideas on improving the speed?

Well first of all you need to identify what the expensive parts of your code are. Maybe some of your calculations are common for all points and can be done only once in advance ( f.e in initRaster() ). QwtPlotSpectrogram always renders in horizontal lines - so if your calculation has common parts for the y coordinate you can use this. You can also build an array of values in advance (maybe depending on the parameters of initRaster() ) and use some simple sort of resampling ( f.e. next neighbour ) inside value().

Depending on your requirements you can try the QwtPlotRasterItem::ScreenCache policy. It will slow down the initial compostion of the image, but leads to fast resize operations of the plot widget. ( don't use it if you need to zoom in/out ).

my data is stored in dictionaries

Then you should probably implement initRaster/discardRaster and load/unload points into memory. Loading points one by one is often much slower.

Alternatively, could I render the spectrogram in a separate thread?

On a multicore system you can divide the image and render each part in a single thread ( no idea how to do it in python ). This has a linear effect ( 0.25 on a quadcore ).

Uwe

[a_kaa]

Thank you, Uwe. It wasn't actually any of these problems, but your post gave me the idea to simpy try and put the spectrogram example into my framework. When that was still too slow (whereas the example on its own isn't), I figured the reason must be that I'm using it inside a QGraphicsScene. I didn't think the impact would be so big...
I'm doing the rendering in a separate thread now, which is okay by me - at least it doesn't freeze the whole application anymore.
(BTW, I'm not actually calling value 1000*400 times, that's just the displayed size. My bad. And by "dictionaries" I meant the Python data type, which should hopefully already be in memory ;-) ).
Thanks again and sorry for pointing the blame in the wrong direction.