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 should note that I could run the OpenGL demo, but it doesn’t render Components using OpenGL (unless I’m mistaken)
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.
Thanks; that’s not what I understood from reading the docs. And I’m not getting the regular paint() happening either, so I’m confused…
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…)
Glad to know I’m not the only one. I only started looking into this because paint speed on Android is abysmal.
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?
Are you using Xcode 10? I’ve seen various reports about OpenGL bugs when building with Xcode 10 / the newest macOS SDKs
I also recall seeing lots of OpenGL related commits with JUCE 5.x… so you might wanna give the newest version of the library a quick try
Xcode 10.3, though I doubt that’s the specific problem. Would like to hear from the JUCE team on this.
I can’t use Juce 5, my (commercial) license is for v4, so I’m stuck unless I pay up, which I can’t afford.
I should try this on Linux to eliminate Xcode 10 being the problem; it’ll have to wait for that test, though…
These are what I was referencing
https://forums.developer.apple.com/thread/113096
The latter makes it sound like Xcode 10.3 should be okay, however I run OSX 10.12 with Xcode 9.3 and JUCE 5 so I haven’t had direct experience with this yet
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
