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:
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).