OpenGL interface renderer with OpenGLRenderer component broken - OpenGL Demo misleading

General JUCE discussion
1

Hello,

I’m developing an application with two components derived from juce::OpenGLRenderer whose contents are rendered in two separate threads in the renderOpenGL() methods.
Since I am a bit concerned about the perfomance of the whole user interface I was investigating the possibility to use the juce OpenGL interface renderer for my other components (a timeline, some trees, …).
Switching the renderer is easy so I gave it a naive try. It seemed to work well on a Intel HD GPU but I had problems with flickering in my OpenGLRenderer components on a Nvidia Quadro GPU.
I decided to test the juce demo application with different GPUs to see how the OpenGL Demo is working with the OpenGL interface renderer.
Everything seemed to work flawlessly until I realized by chance that the Demo app is silently switching to the software renderer when the OpenGL tab is openend.
I must say that I was very surprised about that. At least I would have expected a message to the user that the renderer is switched to the software version.
When forcing the Demo App to stay with the OpenGL renderer I realized that the Demo App has even more problems than I had to this point with my own app. The OpenGL Demo shows the same flickering on my Nvidia GPU but it does not show anything on the Intel GPU.
Since there is also no comment in the source code I am a bit helpless about the current situation.

Is this a known issue and the problems will be fixed and switching back to the software renderer in the demo is just a temporary hack?

Or is using the OpenGL interface renderer together with the OpenGLRenderer component not possible and won’t be possible in the near future?

I would be very thankful for an answer to these question.

Best regards,

Jan

Some information about the system:
Juce version 5.1.1
on a ThinkPad P70
Windows 10 Pro, 64bit
Intel HD Graphics 530 (driver 21.20.16.4678)
Nvidia Quadro M600M (driver 382.50)

1 Like
2

Yes, the demo is a bit confusing in that sense. As you know there isn’t really an “Open GL interface renderer”. You can only attach a GL context to a JUCE component. That JUCE component and all of it’s children will then be rendered with OpenGL.

There are a few limitations to this. First of all, you can’t have any of the child components also be attached to a different OpenGLContext. This will result in problems with z-ordering and clipping.

Also, we know that some GPUs struggle to cope with the situation where a parent component (not attached to an OpenGLContext), has two child components which are both attached to separate OpenGLContexts - you will get the flickering you observe. Often a driver update will fix the problem.

To avoid the situations described above, the JUCE demo will turn off OpenGL rendering for the side menu when running the OpenGL demo. However, the complete demo area is still completely rendered with opengl (as the top-level demo component attaches to a gl context).

If you have multiple components requiring opengl and you want to render all GUI components with OpenGL, then I strongly advise that you attach an OpenGLContext to the top-level component only. The top-level component can then keep track of all the subcomponents which require renderOpenGL callbacks and simply forward the renderOpenGL callback to them.

3

Dear Fabian,

thank you for your answer and your given advice.
It sounds like a reasonable solution and I will have a look into it probably next week.

Best regards,

Jan

4

Just as a follow up for future reference:
The solution with a single OpenGLContext attached to the top-level component and the forwarded renderOpenGL callbacks to multiple subcomponents works very well.

6 Likes