We’re currently porting our application from Obj-C to C++.
We have set a JUCE OpenGLContext as the main window’s render context and as we need to do some more OpenGL drawing in a subcomponent, we are forwarding the calls to that component from the main window’s renderOpenGL calls as suggested by Fabian in this thread:
Our main rendering pipeline uses one main shared context which holds all the texture and frame buffer names, so we’d need to share this with the main window’s context.
However, if I set a shared context to the main window’s rendering context before attaching it to the component, the UI is not redrawn anymore as it should. This can only be triggered by resizing the window for example. Is there any reason for that or is there another way to handle this problem?
Is there a special reason why you want to use shared contexts? I’m running this setup with a single context held by the main window and also used by the sub components. Two of them are doing complex renderings with textures framebuffers etc… Or is it not possible to pass the main context to your existing pipeline?
The render view in the component is only one “output” of a video rendering pipeline using shared contexts to provide rendered images to several output devices. The output devices do their compositing each on their own context on background threads.
I tried passing the existing context to my pipeline as the “root” context where the shared context used in the rendering pipeline is based upon but then adding a second render window for example isn’t that easy as it gets a new context (I might be able to share the main window’s context, not sure).
We just found out that we can stick to our “old” approach of using a separate OpenGLContext on the video rendering component which then uses the shared context of the rendering pipeline if we make sure that we don’t have “overlapping” contexts.
The main window’s context was rendering the whole window including the video rendering component and the video rendering component was rendering itself. That caused trouble. We now assigned a separate rendering context to all top level components within the window. Each of them will render a non-overlapping section of the window. That works great so far and doesn’t seem to cause a performance hit.
