From what I’ve read, rendering Components using OpenGL is as easy as creating an OpenGLContext and attachTo(theComponent).
But when I do that on my macOS 10.14.6 system with Juce 4, the component shows nothing more than gray and the app hangs. If I tell it to setComponentPaintingEnabled(false) then I get a black component.
What should I be doing differently than what I mentioned?
I can’t help you with the OS-X specific issue of nothing showing on the component. But my current understanding is that the OpenGLContext is to allow OpenGL rendering (with OpenGL calls) together with a regular component, which will still have its heavy duty drawing operations (implemented in the paint() method) done on the CPU. The end result can be that you are spending cycles on both the CPU and GPU and don’t get much, if any, improvement on the CPU usage.
I have been confused about this for a long time myself. I am actually still not completely clear about the purpose of the OpenGLContext. Hopefully someone can give a definitive answer for it being useful for GPU accelerating ordinary Component paint()s or not…(The OpenGLContext does something at least on my Windows system because when I add it to heavy component, the GPU starts getting utilized. But I am at the same time observing heavy CPU usage too…)
It is correct that even with the OpenGLContext, the rasterization of Component painting still happens on the CPU. The benefit you get is that since OpenGLContext works in the context of CachedComponentImage, drawing the components that haven’t changed is very quick (blitting GL texture)
Of course this means if you’re calling repaint() very often that you may have a higher overhead than when you’re not using the OpenGLContext, since now you’re adding the cost of updating an OpenGL texture as well as doing that edge-table rasterization on the CPU
OK, this is so far the best explanation I’ve read. So the OpenGLContext is basically useless for GPU accelerating Components that are updated often, for example with a Timer? Which would be a bit ironic, since that is the situation when the acceleration is needed the most…
Yeah I’ve basically delegated any “quick moving” parts like RTAs, meters, etc. to being rendered via actual OpenGL calls (OpenGLRenderer) and then left our more static components to JUCE’s default OpenGLContext painting
OK, but to my original question: why is my “OpenGLContext” attached Component hanging instead of painting? Should I be doing something other than just creating that context and attaching it, as all the docs I’ve been able to find have said?
Thanks. As I mentioned initially, I can build and run the demo programs, but since they don’t “attachTo” a component without doing anything else, they’re irrelevant. But they do show that OpenGL does in fact compile/work on my OS.
The OpenGLContext attatched just means that the painting renderng will be done on hardware (your gpu) instead of software, and AFAIK this is done by caching the context in it’s own thread.
You don’t have to do anything else unless you wanna use real OpenGL, and then you should work with OpenGL primitives like in the tutorials/demos about the matter.
But back to the attachment, with it some stuff like rasterizing will still occur in your CPU, so sometimes you will see your CPU usage even halved and sometimes it will do more harm than good depending on your painting methonds (path stroking, image drawing, etc) and the frequency of repaint. It’s a matter of profiling and going with the one that performs the best