Significant performance improvement using OpenGL rendering

[Adrian Musceac]

Hi,

I have replaced the default software rendering method of the FFT and
waterfall with an OpenGL widget and discovered a significant improvement
in performance allowing me to run a 32768 point FFT at 50 FPS with
basically no degradation of performance.
There are a couple of minor painting artifacts which I'm sure can be
avoided somehow.
Video at https://www.youtube.com/watch?v=F2bG_SM5J7o

The code change is very simple and can be configured as a build-time
option. For this reason I am not submitting a pull request as my version of
GQRX is very old.
Of course this will not work if you don't have hardware OpenGL
acceleration.

Credits to Emilian Huminiuc (i4dnf) for the original idea.

73,
Adrian (YO8RZZ)

[Alexandru Csete]

On Wed, May 11, 2016 at 9:53 PM, Adrian Musceac <kant...@gmail.com> wrote:
> Hi,
>
> I have replaced the default software rendering method of the FFT and
> waterfall with an OpenGL widget and discovered a significant improvement
> in performance allowing me to run a 32768 point FFT at 50 FPS with
> basically no degradation of performance.
> There are a couple of minor painting artifacts which I'm sure can be
> avoided somehow.
> Video at https://www.youtube.com/watch?v=F2bG_SM5J7o

Have you tried to do a "release" build instead of a "debug" build.
That may also give the same kind of performance improvement ;-)

Alex

[Adrian Musceac]

Hi Alex,
You're right, I hadn't tried it on a Release build. It's interesting that the
improvement is seen on a Debug build but insignificant on a Release
build. I will still keep this change because without it I get stutters in
Debug builds which I use more frequently. Otherwise it's safe to say
there is no improvement.

Thanks,
Adrian

[Alexandru Csete]

On Wed, May 11, 2016 at 11:29 PM, Adrian Musceac <kant...@gmail.com> wrote:
> Hi Alex,
> You're right, I hadn't tried it on a Release build. It's interesting that the
> improvement is seen on a Debug build but insignificant on a Release
> build. I will still keep this change because without it I get stutters in
> Debug builds which I use more frequently. Otherwise it's safe to say
> there is no improvement.

Hi Adrian,

Well, I think it can be explained... If you use hardware acceleration
then most of the drawing is performed by hardware and it will be the
same regadless of the build time. However, if you use software
rendering then Qt will probably use an unoptimized debug version of
the drawing library for debug builds, which will be slower than the
optimized version.

I will try at some point myself and measure the improvements with
hardware acceleration. It may be useful adding it as a runtime option,
so thanks for the tip in any case.

Alex

[Adrian Musceac]

Thanks! I have to say that for me the performance improvement is
significant and can be noticed even in the Release build, especially on
large sample rates where the CPU is pushed by the Gnuradio FFT code.
Before this change, I would get audio stutters when increasing visual
FFT size or the FPS. With this change, I get no such issues.

My CPU is a 2.7 GHz dual core i7 running Debian 32 bit.

Cheers,
Adrian