Preserve waterfall during zooms and pans

[yuzawa-san]

• I wanted to have some level of preservation when panning and zooming in the waterfall, so when I'm looking around I can see some rudimentary history of the waterfall. Currently, the waterfall data is not always aligned with the current frequency scale. I guess there is technically a bug with the hover tooltip reporting the incorrect frequency (but correct times) on the waterfall, which this PR fixes.
• I did some research to see if there was an easy or efficient way to do this, but found that the cheapest way would be to have a partial persistence. I considered storing each waterfall line as a timeseries, but it did not seem cpu or memory efficient. Also it did not work well with all of the existing features.
• The compromise I came up with here was to do "destructive" operations on the waterfall QImage. If the frequency or center frequency changes the waterfall is cropped and moved (using QImage::copy) to make sure the waterfall still lines up with the new frequency range.
• Something similar happens with zooming in and out (using QImage::scaled), and in both cases the waterfall data is always aligned with the current frequency range.
• NOTE: the zoom in is not smoothed to keep discrete bins identifiable, but the zoom out operation is smoothed to make the small version more representative of the actually source buckets.
• I added a moveWaterfall method and attached to plotter movements.
• Also new_span_int was calculated but never used. I use it now to ensure getMinFrequency and getMaxFrequency do arithmetic correctly.

See it in action:

https://github.com/user-attachments/assets/1fe284b8-9388-4e6a-8d99-ffe2791423ea

[argilo]

Thanks! This looks like a useful change. I did some initial testing and it appears to work well. I'll let you know once I've had a chance to do a bit more testing and code review.

[argilo]

An observation:

Because the RTL-SDR driver has a very large default buffer size, it can take some time for things to get back to the correct place after retuning:

Changing the device string to something like rtl=0,buflen=16384 solves the problem.

I'm not suggesting that anything needs to be changed in this PR; gr-osmosdr should probably use a smaller default buffer size. (SoapyRTLSDR has the same issue, although its default buffer size is smaller.)

[argilo]

Another observation:

Tuning by a large step clears the whole waterfall. This may be a reasonable thing to do, but could also make it harder to scan for signals. I'll have to play with it some more to see how it feels.

[vladisslav2011]

Pros: Each waterfall column always corresponds to a single frequency, that match the panadapter frequency axis. Clicking the waterfall column anywhere results in tuning to this frequency independent of previous zoom/panning changes. That's intuitive behavior. Cons: The signal history is lost after zooming in/out, leaving large black areas. Zooming in results in blurry scaled lines without useful information.

I've experimented with the plotter in the past, trying to preserve the waterfall history while panning/zooming, but decided to implement only "persistent waterfall during IQ playback" feature and gave up implementing full redraws when the DSP is running. Implementing the "persistent waterfall" during real-time operation requires us either to keep all FFT bins, that correspond to each waterfall row - it needs too much RAM in case of 4k display and 1M+ FFT size or to keep all samples, needed to re-render all waterfall lines in iq_fft block history - it needs even more RAM in case of high sample rate and long waterfall time span. This is not the case when playing an IQ file as any block of samples can be easily fetched from the HDD/SSD, so no extra RAM is wasted, but the rendering speed is limited by the storage media random read rate...

It may be better to implement slightly different feature: store frequency/zoom information with each waterfall line. Pointing a mouse to a waterfall pixel would result in correct frequency displayed in the tooltip and clicking a waterfall pixel would result in tuning to that frequency independent of current plotter center frequency/zoom level. It would not require too much RAM, but may be less intuitive to a user...

[yuzawa-san]

yes i did note that there was that slight lag in certain circumstances which cannot be helped for the reasons you mentioned.

i also agree with the pros/cons. may i propose a hybrid solution: 1) make this feature optionally active by adding a checkbox in the FFT settings. 2) store the frequency ranges for each waterfall line like @vladisslav2011 mentioned such that the click/tooltip is correct whether this feature is enabled or not. i like the idea, but it is more of a bugfix rather than a new feature, so i may make that a separate PR and then work whatever comes of that into this PR later.

what do you think?

[yuzawa-san]

please consider this https://github.com/gqrx-sdr/gqrx/pull/1392 which is less invasive than this PR. i may resurrect this PR in the future but as a conditional feature.