I have a feeling Jules will object to OpenGLContext being subclassed. It does so much, using it as a base class to get one feature seems wrong.
So I have a proposal that better fits the way I want to use sharing, hopefully it fits with o=your cases?
class OpenGLShareGroup
Each new OpenGLContext can share with it or not. Resources can be registered with it, much like with an OpenGLContext, but they will now be shut down when the last context in the group shuts down, or the group itself shuts down.
At some point we could add a ‘persistent’ flag that would allow an offscreen context to be created.
A key advantage would be that no other contexts are needed. Currently, AFAICT, CachedComponentImages use their own context - Jules, context switching in the middle of a rendering pass is a big non-no. Now any work that needs to be done on a context can be done on any context in the group. So, for instance, if I want to make an Image available as a texture, I add it to the share group. Now, the first context that wants to render with it will create the texture (will involve some locking, but no context switching). It’s then available to any members of the group, and it’s still available even if one or all classes disappear.
class OpenGLShareGroupMember
a fairly lightweight ABC class that links to and from the share group. It should be lightweight enough that external, non-juce contexts can be wrapped and join the group, or the group can start with a non-juce context.
Any comments? I’d love to be able to not roll my own offscreen contexts, and it should improve the current Juce GL system.
It should also be relatively simple to implement with a minimum feature set: just the OpenGLShareGroupMember class as an ABC for sharing, thereby no misuse of the heavyweight OpenGLContext class.
setContextToShareWith (OpenGLShareGroupMember* share)
or
setContextShareGroup (OpenGLShareGroup::Ptr shareGroup)
Bruce