I’ve just made a spectrum analyser. And to draw the graph I used Juce Paint class, and Path.lineTo function. But for bigger resolution (more path points) it starts to be very slow and lag frienfly. Bigger resolution I mean something about for example 10000 points path.
Of course I also suppose maybe my code isn’t optimal. But I think it’s the Path and Paint class. Why I think that? I am not sure but for simply sine wave it works great even for 20000 points of path. But for more complex signal, like saw wave - which is still not very complex of course - but my analyser starts lagging. Why?
As juce uses a scanline renderer, rendering paths that intersects a lot with horizontal lines is slow(ish). Unfortunately a spectrum usually does that a lot while a sine wave doesn’t.
The usual thing to do with analyzers is to avoid creating a path with a lot more resolution than the screen. That means in the spectra case for high frequencies an average value of multiple fft bins is used and a path with maybe ~1000 points is used for rendering.
If you still want to render 20000 points you could try rendering into an image that is ninty degrees rotated and then rotate the image back. I never tried this (but maybe I should), but it should be a LOT faster for a spectrum which has precisely one y value per x value.
Personally I find it a bit annoying that juce uses horizontal scanline rendering as it’s mainly used for audio things and most audio graphs have a lot more horizontal line intersections than vertical ones. (spectrum/waveform/envelopes).
I use OpenGL for any substantial real-time visual feedback.
It’s not for the faint of heart, but the method I use is:
- Pass points locations to GPU
- Use geometry shader to generate lines with joints
- Use the fragment shader to anti-alias those lines base on line thickness and distance from edge
I have dozens of lines taking up a lot of space and are drawing at 60 fps. The CPU usage remains pretty low. That said I’d rather not know how much time development time I’ve spent just on rendering lines
Some SR products written directly with OpenGL. When it works, it’s much smoother.
However, in terms of compatability OpenGL especially with bad drivers under Windows could generate crashes the moment context being created.