OpenGL context handling

General JUCE discussion
1

Howdy folks,

I have some concerns about the way OpenGL contexts are used in JUCE up to now. I see that each OpenGLContext is attached to one (!) Component, which I see as rather problematic from a design perspective. Actually it should be the other way around, an OpenGLContext instance would need to be associated to each Component, with the regular case being that most/all Components share the same context if there are no specific requirements to have several of them, which is a rare case.

I have worked for the last 10+ years in the computer graphics and real-time rendering domain, and can tell you that normally it's absolutely an exception rather than the norm to be working with several contexts at all. Although it is possible to use shared contexts, this is rather problematic from a performance perspective, since you have no guarantees whatsoever and the performance can vary greatly between driver implementations. I see that JUCE makes extensive use of context sharing, but to be honest, having 20 shared GL contexts for 20 Components drawn into the same window will lead to very bad performance characteristics, especially if lots of GPU memory transfers happen. It is not the way things are intended to be done within the OpenGL standard. Here is a writeup of some of the issues related to GL context sharing:

http://blog.gvnott.com/some-usefull-facts-about-multipul-opengl-contexts/

We are developing an audio analysis/synthesis application which will make extensive use of real-time rendering where the output will be split into many Components. Responsiveness and render performance are key requirements for us, so I see the current state of affairs as quite problematic.

We will have to live with the way things are currently done in JUCE3 and see how bad the performance characteristics will actually be on our target systems / driver implementations, however in the mid- and long run, this definitely needs to be addressed! I don't know how many of the JUCE developers are deeply into the real-time rendering domain, but as said I have some experience with these matters, and in case you can use any help / support / whatsoever in these regards, I gladly offer my support and would help redesigning and even implementing things which will be necessary in that context (no pun intended).

Best, Patric

2

Thanks - we already had plans to make it possible to share a single context between various nested renderers, and will be adding that pretty soon.

Some of the guys at ROLI working on another project (that sounds like a similar use-case to yours) have already got a system like this running , we just need to tidy it up and add it to juce.

3

Great to hear about that. Do you think it might make it into JUCE4? I'm keen on switching to the new version as soon as it's available anyways, while other people might have reservations regarding buying licenses etc. (we develop a commercial application here). That would be a great argument for switching, since as said, rendering performance and responsiveness are some of our key requirements.

4

It may not be there for the initial V4 release, but it'll be one of the first things we add afterwards, as it's a priority for us too.

5

Just one point, to make it explicit, in my conception the renders should not have to be nested in order to use the same context, but it should be possible with different Component objects altogether. Don't know if that's what you implied, just want to make sure.

6

Yes, that's the idea. The entire window would use a GL context and everything in it would take turns at rendering into it.