Not accident. As told in user manual.
"When the number of points in the time domain, N, is less than 2 Mpts, the FFT takes the number which is an integer power of 2 closest to N."
It is obvious that it needs to round down to the next power of two, since it can only discard, but not "invent" samples.
But what is the "number of points in the time domain", from which the power-of-two FFT size is then derived?
I actually made a mistake when I wrote "FFT window size was between 50% and 100% of the screen width". Checked again, and noticed the mistake.
It only applies to the screenshots with >= 50ns/div, but not for faster time bases.
Below is an updated table, extracted from Martin72's screenshots. FFT window sizes range from 0.512 to 8.192 screen divisions.
Why is the FFT window size so much smaller than the screen width at <= 20ns/div? This can no longer be explined by rounding down the screen width (in samples) to the next smaller power of two.
The interpolated samples for the full screen width need to exist anyway, otherwise the trace could not be displayed. So why not use as many of them as possible?
For instance: 5ns/div reports 100 (raw) samples @2GSa/s (which is the width of the screen).
With 100x interpolation (-> 200GSa/s) this gives about 10000 samples, and a power-of-two FFT size of 8192 were possible. But it chooses only 512.
2000ns/div: FFT window: 16384 ns, or 8.192 div (2GSa/s)
200ns/div: FFT window: 1024 ns, or 5.12 div (2GSa/s)
100ns/div: FFT window: 512 ns, or 5.12 div (2GSa/s)
50ns/div: FFT window: 256 ns, or 5.12 div (2GSa/s)
20ns/div: FFT window: 20.48 ns, or 1.024 div (50GSa/s interpolated)
10ns/div: FFT window: 10.24 ns, or 1.024 div (50GSa/s interpolated)
5ns/div: FFT window: 2.56 ns, or 0.512 div (200GSa/s interpolated)
5ns/div: FFT window: 2.56 ns, or 0.512 div (400GSa/s interpolated)