initially we realized our views with only default Juce Components. With some of our views we hit a preformance problem and realized them with OpenGL. Each of thos components has it's own renderer which gets added to an OpenGLContext.
Now we hit some problems with dragging, resizing and overlaying with the mixture of normal and OpenGL drawing and wanted to draw everything with OpenGL. When we now add an OpenGLContext to the topmost Component all normal Components get drawn perfectly fine, but those with their own context and renderer are left out. The renderOpenGL() methode gets called but I never see anything that is rendered their.
At first I thought we only should have one context at all, but you can only attach one renderer to it and we have a renderer per Component.
How can we reuse the renderer of the first OpenGL Components but use the default renderer for the rest?
We have a few similar problems with our NOISE app so are motivated to smooth things out… I did look into setting up a single GL context with multiple OpenGLRenderer subcomponents a while ago, but hit a few snags involving thread-safety that needed solving before it was possible. Will look at that again…
I’m not working on this project anymore, not even for the company, but I’ll try to explain what we did.
We added a OpenGLRenderer that can have child renderers, the parent renderer is only there to call every subrenderer. So every component that gets added to our view will register its renderer on the parent renderer.
Hope that helps.
A related question though:
If we use a single OpenGL context, but multiple (child-)OpenGLRenderers for different components in the GUI (just like described by @0-matic above), how does the OpenGL-accelerated JUCE renderer actually cooperate with the custom GL components? I mean, what will be rendered first and what will be rendered last? Can JUCE callout-boxes etc still be compatible with this concept? Or will custom OpenGL components always be on top of any JUCE-rendered content.
Any updates on this? We have multiple OpenGLRenders in most of our plugins and have hit a couple snags. Coming from Cocoa development, we’re accustomed to them all being rendered on the same thread (via CVDisplayLink). Because they share some data, the Juce implementation would be a good deal more complex if we need to be able to handle rendering from multiple asynchronous threads.
Yeah, sorry, I started on this a while ago but got interrupted, and it turned out to be a bit more complex than you’d expect. We will do it, but can’t promise when!
Hate to nag, but any word on this? For the moment being I’ve created the above mentioned child renderer hack that works for specific use cases but something more flexible & robust from the JUCE team would really make my next releases much easier to implement. Many thanks!
