juce_OpenGLContext.cpp fixes! iOS / Android big improvement!



So I’ve had a little free time at the day job to keep looking into GL issues on iOS and Android. With the removal of 2 lines of code performance is greatly improved on iOS and Android for when child Juce components are rendered. IE the renderComponents / paintComponent() path.

It turns out that there is an errant call to context.makeActive() that is unnecessary and very costly on iOS and Android that isn’t so much of a problem on the desktop. My guess is that was added when working on the desktop support perhaps even a throwback to the need to do something similar for pbuffers back in the day. Nonetheless it’s not needed for things to render correctly with FBOs.

It’s around line 200 in juce_OpenGLContext.cpp. I did however in my tests comment it out and also wrapped it with a conditional checking “isActive()”. I think this line can be removed though.

if (!context.isActive())

Things popped to life w/ iOS / iPad2 with my GLChildComponent test where I have a bunch of Juce sliders controlling my GL child component render system. As before there were major glitches when a slider was changed. Now without makeActive() being called even with automating the slider changing its parameter and the GL child component bounds (which right now naively initializes a new backing FBO) things are rather smooth compared to before.

The other line that seemingly can be removed from juce_OpenGLContext.cpp is in triggerRepaint() around line 568:

Unless I’m mistaken this is an unnecessary call since any child painting will occur in the OpenGLContext::CachedImage paintComponent method if it is enabled. Commenting it out doesn’t affect desktop or iOS rendering, but gives one less artifact / problem on Android seemingly.

There are only a few more major issues I can see with GL support on Android. One is when a menubar component or other components that share a hierarchy with an OpenGLRenderer enabled component on Android repainting Juce child components gives odd artifacts intermittently unless the OpenGLRenderer component takes the full bounds of the screen / window. I verified this by adding a simple custom component for the menubar component that is solid blue and intermittent artifacts that for the most part are the same height as the menubar are solid blue when child components including my GL child components are rendered. I think this can be solved sooner than later on my side.

The final major issue is debugging why JuceDemo locks up on Android when switching to the GL rendering demo. Not excited about that one, but it is what it is and will be likely harder to debug.


Cool, thanks for your insights!

Re: the makeActive(), I’m pretty sure it is needed on some platforms, but yes, wrapping it in a conditional is a great idea, I’ll do that.

And yes… that repaint does seem to be unnecessary as far as I can see. Thanks, I’ll zap it!