SDRPlusPlus
SDRPlusPlus copied to clipboard
AlexandreRouma
Optimize WaterFall::doZoom and fix imprecise zooming
The waterfall was jumping around when zooming, it made VFOs randomly (float imprecision) offset from signals displayed on the waterfall. I also optimized the doZoom inline method. Now it's roughly twice as fast.
goddamn I didn't remember that part of the code being so horrible. Must have been one of these "4am" pieces of code...
Could you explain in more detail the mod to doZoom? I'd recommend commenting the code in that function a bit more.
I've added some comments, hopefully it's clear now. I tried googling a way to make it even faster, to no avail. I think the entire FFT should be moved to a separate thread anyway. I like having the full update functionality enabled and even with my 1080p screen and $25 SDR dongle, SDR++ lags when zooming fully out. Or, maybe, at the very least, the zoom slider could be debounced if full update is enabled.
I removed the ceiling function and the other variable. It was causing the loop to always check the next sample in the buffer, even if the display is scaled 1:1. At least, I think.. :P
The FFT is already in it's own thread. doZoom is called from the aquireFFTBuffer (or whatever don't remember the exact name) function which is called by the DSP handler code. Only the ImGui rendering code runs in the main thread. I'll check the code in detail when I get the time, extremely busy with university work at the moment. Considering I'm really close to releasing 1.1.0 I need to garanteed validity and stability.
In that case, could you change the variables factor, sFactor, uFactor and id to doubles? That cannot break anything and it will fix the issue with waterfall jittering left and right.
EDIT: Right, but the FFT zooming function runs in the main thread and doing the doZoom algorithm for all lines of the waterfall is slow. But it's not that bad. It's definitely not critical to make it run in 40 ms instead of 80 ms, and even that for high sample rate devices and only when zoomed out all the way.
In that case, could you change the variables factor, sFactor, uFactor and id to doubles? That cannot break anything and it will fix the issue with waterfall jittering left and right.
I am 99% sure the issue is not float imprecision. it's simply the FFT bins being forces to stay aligned. I will look into changing it to doubles since most of the other parts of the waterfall already use doubles. Switching any variable representing a frequency or bandwidth is a good thing.
Right, but the FFT zooming function runs in the main thread and doing the doZoom
That is wrong. The only case the FFT zoom is ever run in the main thread is in case full waterfall update is enabled and the zoom or min/max level is changed, when switching color pallet or when the window is resized. (aka updateWaterfallFb). These is no reason to run it in another thread as it has to be synchronous.
Edit: fixed the incorrect typesetting of the quote cutting out half of it