I decided to use OpenGL rendering for my next plugin since I know I’m going to be doing a lot of drawing with paths. So all I did was attach the editor to the OpenGLContext object. I am currently drawing two spectrum analyzers and the performance is a lot better than with the JUCE native renderer. However, I’ve noticed that the painting stutters every now and then and I don’t really know why.
Hmm probably not the same thing, but the last time I had something similar with openGL performance it was because I had overloaded the renderOpenGL() method with too much work on each render cycle. There’s no chance of backed up requests on the message thread is there? Does openGL pick up cached data on each draw, or does openGLs refresh rate drive the recalculation of the spectrum data?
Admittedly I’m pointing out the silly mistake stuff but hopefully it might help rule out some stuff.
Thanks for the quick response, Jeff. I’m not entirely sure what you mean, though. I’m simply calling repaint() from a timerCallback(). The repainted component then pulls audio data from a lock-free queue and goes from there. I don’t know if there’s something specific I need to take into account, though, since this is my first time instructing JUCE to render with OpenGL.
About the reply of Jeff, I think there is a common misunderstanding with the openGL-renderer.
Using the OpenGL renderer may improve the redraw performance, but it still depends on the message-thread. And if something time-consuming happens on the message thread, it will make the animation stutter (and this is very often if you are using a plug-in inside a host, which often shares the message-thread with all other plugins).
If you really want smooth animation, you can do it inside the renderOpenGL()-callback (look at the tea-pot demo), via low-level openGL commands, shaders etc…
I’ll second the recommendation to use renderOpenGL callback. I’m using OpenGL with pixel shaders and multiple render targets, along with component rendering both over top of the OpenGL and rendered into the OpenGL render target. Everything is smooth, no jitters.
Thanks for the reply, Christian. That would be the best option for fast rendering. The question is, why the JUCE renderer doesn’t stutter but runs smoothly instead, even though they run on the same message thread?
Try setting only the drawing components as OpenGLAppComponent instead of attaching the editor. This won’t even need a timer, just override initialise(), shutdown() and render(), and call shutdownOpenGL(); in the destructor and repaint in the render function
Disclaimer: I’m not entirely sure that this procedure is correct or without problems. At least It works for me
Thanks @Marcusonic and @splintersilk. Using the clear function got rid of the black background and freezing. However, I’m sadly still getting the stutter. I guess I’ll use the JUCE rendered for now and see if the performance is “good enough” once I have the plugin finished.
do a test, ignore the paint function. clean with a different color on render() in each pass to see possible stutter. This could at least give you a clue if the problem is in the Opengl thread or if there is some kind of overload in the drawing.
As long as you are using JUCE drawing methods on moving components, OpenGL is unlikely to help you. What happens under the hood, is the OpenGL thread takes a messageManager lock and the juce drawing routine is still done on the message thread, only it’s drawn into an OpenGL frame buffer instead.
You have 2 options to improve stutter.
Shaders/vertex buffer style OpenGL drawing in the render loop. No juce drawing.
Do your expensive/time dependent juce drawing routines on another thread into an image, and in the main paint routine just draw this image.