Do you think that I’d write two sets of rendering code, one which is fast and another which is slow, and then I’d make everybody use the slow version unless you find the secret, undocumented way to enable the fast one!??
The rendering is fast as long as you don’t use it inefficiently, and I know of several juce-based real-time FFT displays, so it’s totally possible, but when you’re doing something like that you have to be careful. You need to profile your app to see which rendering ops are taking the time, and then work out how to draw your stuff with the least overhead.
As jules stated, its probably not the graphics calls thats making your code slow. I’ve done this many times on much slower machines then yours with much success just using bitmap blit calls. So just some things to consider:
make sure you color map is efficient, I usually use a LUT for mapping the floating point power spectrum to an RGB value
(non-scrolling display)
I typically pre-allocate a bitmap that is exactly the size of the spectrum display, write my RGB values to it as the come in, and the blit the bitmap to the display
even better just blit the part that has changed,
(scrolling display)
if yours is a scrolling spectrum then blitting the whole bitmap is fine
when you want the scrolling effect use an efficient 2d image circular buffer (should allocate twice as much memory as needed for a single image, read and write pointers are offset by the size of one image and are incremented as you copy in columns of data)
