Comparing to plug-ins written using VST GUI it is clearly not an issue for them, which is slightly concerning.
It's painful when we see people post things like this - it creates unfair FUD around juce's drawing code! There are plenty of juce-based metering apps out there that perform very well, but you can't just approach something like this naively and expect the framework to magically make your code run fast - getting good graphics performance requires some careful work on any framework.
The juce rendering engines are very fast - at least as fast as anything you'll get in VSTGUI or other frameworks.
Are there any improvements to this upcoming in JUCE 4 or planned for the future?
Interesting question!
- The CoreGraphics renderer: Impossible to improve it, because it's obviously bottlenecked by the performance of CoreGraphics itself.
- The software renderer: Can't be improved, because although its compositing code could probably have a few more percentage-points squeezed out of it, on modern devices it's entirely bottlenecked by the huge memory bandwidth required to get high-res bitmaps onto the screen. CPU-based rendering is simply not a feasible option for retina-size displays now.
- The openGL renderer: This is already very fast, but it's bottleneck is in the time taken to rasterise paths, which isn't a task that can be moved onto the GPU, so there's not really anything else we can do to make this faster.
But.... New post-openGL frameworks are appearing like Metal and Vulkan, and we'll be able to write some crazily-fast rendering engines for these APIs. We're looking forward to working on that, it'll be a fun programming challenge!
But to answer your problem - just like for any performance-related problem the answer is always:
PROFILE YOUR APP!
There's really no point in asking for help until you understand where your CPU is being used, and the results are almost always surprising.
I’m aware that using OpenGL will certainly help the matter, but from what I can see there isn’t a way to use an OpenGL Graphics context to pass down through the paint methods.
If you're drawing bitmap images, the GL renderer will be faster by a ridiculous amount. Have a look at the demo app to see how you can enable GL-based rendering - it's only about 4 lines of code and a bit of messing-about to do so. (We're going to add some helper functionality soon to make it a one-line change to enable it)