Our existing 3D software is interested in benefit of OpenGL Juce component drawing capability,
for extra editor in secondary tool window.
Main output was the first created GL thread/window and must stay managed by non Juce code.
For this, it can be interesting to share display-list of OpenGL context created by third party code with Juce ones.
I understand that Juce native context is created asynchronously so there is no possible accessor like:
(Inspired from ComponentPeer::getNativeHandle() with HWND on Win32)
By the way, in addition of existing method.
It should be possible to add new
(nativeContextToShareWith hide a HGLRC on Win32)
Win32 implementation of OpenGLContext::NativeContext could manage it like this :
// existing sharing with juce based OpenGL context:
if (contextToShareWith != nullptr)
wglShareLists (contextToShareWith->renderContext, renderContext);
// new sharing with native third party OpenGL context:
if (nativeContextHandleToShareWith)
wglShareLists ((HGLRC)nativeContextHandleToShareWith, renderContext);
I suppose that similar implementation could be written for other OS.
Do you think this feature could be integrated in further Juce release ?
Thank you in advance for your attention to this matter.
Juce has had context sharing for a long time, with similar methods to your suggestion. I actually use an offscreen OpenGLContext child class.
Having said that, it seems to be broken right now… need to look at why in the next few days.
Bruce
I’m currently working with Juce 2.0 master branch.
Juce OpenGL module have many changes since 1.53 branch.
Jules has worked a lot on multi-plateform juce::Component painting over custom GL drawing.
(performed by user renderer implementing OpenGLRenderer interface).
Thanks for all of this !
This great new user friendly API have a migration cost anyway.
OpenGLContext is a non heritable concrete class hiding a lot of complex members:
[list][]An instance of a native context class for OS abstraction.[/]
[]A deferred attachment system on juce::Component. (catching component size and visibility events,
when condition are correct , ComponentPeer and GL native context are created or destroyed)[/]
[]And finaly a thread-safe CachedImage hosting the rendering thread for Component blending over OpenGLRenderer draw.[/]
[/list]
Actually the newly created OpenGL context is active on the CachedImage rendering thread and cannot be de-actived any more.
juce::OpenGLContext can only share context of others juce::OpenGLContext.
Good luck for your fixes Bruce.
Huh, I see. What I had was an OpenGLContext subclass that duplicated the juce context creation code, then returned the context as needed.
I guess there’s a new ‘NativeContext’ class now that gets in the way. It actually very like my class… but now the OpenGL juce stuff expects an OpenGLContext to share with, but then it just derefences it.
Jules - that’s a level of indirection that breaks the ability to share juce OpenGL stuff with other areas.
Can we either - pass in a NativeContext (or subclass), or just pass in a raw platform context? What reason is there to have the OpenGLContext class as the share, especially now it’s doing the job of the old OpenGLComponent?
Bruce
Ok, I think we’re saying the same thing. There didn’t used to be two layers of OpenGLContext, and I duplicated the context creation code times three platforms.
The new system doesn’t allow any sharing except with an existing active window - that’s a big problem. It even makes CachedImages less useful. Even using one cached image as an offscreen context to share with would work, I suppose.
But the starting point, as you say, is to share a NativeContext, not an OpenGLContext. Since one app is one platform, the extra level doesn’t help.
Bruce
Posted into the wrong window...
