Sorry for the only loosely JUCE related question, but:
I need to be able to host an OpenGL display that is being manipulated by a 3rd part dynamic library on a JUCE component.
My choices here are:
have the dll / .so create its own display, and map it onto a custom component, or
have JUCE create an OpenGL component, and export the open GL canvas[1] to the dynamic library.
the logical third option, I.E. make the context active, then call into a DLL to just issue open GL rendering commands isn’t an option. The library will need to have access to the underlying OpenGL canvas to do its stuff[2].
Which of the first two options is the best approach?
Additionally, is it even safe to pass a pointer to an OpenGL context to a dynamic library? I.E. can the platform specific class that is referenced by the pointer cross the dynamic library boundary on all three platforms?
[1] At this point I get a little confused as to what goes where too. OpenGL doesn’t provide any windowing stuff, so I guess the context is the canvas, correct?
[2] Essentially all I want to be able to do is to provide a VST like plugin system in my app that allows other people to write plugins that can render to an open gl canvas if they so need. I don’t want these to appear as floater windows though. Because I suspect most people who’ll likely need this facility will be using VTK, they are going to need to have access to the low level open GL instance, 'cos that seems to be how VTK rolls.