I recently updated JUCE to the commit 7b61bdfba9b37bdfb93929eb3e592662f077de91 on the develop branch because I needed this commit to make my plugin usable on MacOS HighSierra after the JUCE7 update that broke it. I wanted to cherry pick at first but it turned out some significative changes have been made to the OpenGL code overall and it was not possible. And this is where my point begins.
I’m not 100% sure, but it seems these changes on the GL implementation leaded to some misordering in GLTextures’ release logic when closing the host while the editor is opened. It triggers the jassert with this associated comment : // If the texture is deleted while the owner context is not active, it's // impossible to delete it, so this will be a leak until the context itself // is deleted.
in the file modules/juce_opengl/opengl/juce_openGLTexture.cpp l.169.
While it should not be a problem because we are indeed closing the context and thus we’re not leaking, I think the assert should not trigger in this case. Let me know if you can reproduce it or if you need more details
Regards.
PS : The changes are great BTW, namely the OpenGL 4 support but also the commit I mentioned seems to have positive effects on OS that were not concerned by this interblocking bug at first but where the GL drawing was getting stuck when many contexts were instanciated (eg: many instances of a plugin).
I didn’t see that issue during testing - under what circumstances do you see the problem? It would be helpful to know the following:
The OS and architecture on which you noticed the issue
The DAW in which you noticed the issue
The set of steps that triggered the problem (if more involved than “quitting the DAW while the plug-in editor was showing”)
The way in which the OpenGLContext is used (component repainting, continuous rendering, custom renderer etc.)
If I modify the AudioPluginDemo to attach an OpenGLContext to the top-level editor, then load multiple copies in REAPER, quitting the DAW doesn’t fire any assertions for me (macOS 12.6, Arm). If I modify the plug-in further, to render a spinning teapot, I still don’t see any problems. I suspect the issue is dependent on the OS + DAW, or on the specific rendering code in the plug-in.
Edit: Live 10.1 on macOS 10.13 also doesn’t trigger any assertions when the DAW is terminated while the spinning-teapot-plugin is still visible.
The OS is Windows 10 21H2, my bad I should have repeated it in my message in addition to the title. I am on amd64 of course. There’s no problem on MacOS whatsoever as far as I know.
The issue occurs in Reaper & Ableton. I can’t test ProTools infortunately because I still can’t run ProTools Dev on my computer despite the recent update. I think it is at least general to VST3 but I think it’s more likely to be unrelated to wrapper type since it concerns OpenGL.
Really nothing else involved
I have 2 contexts with 2 custom renderers and 2 HighResolutionTimer that triggers repainting depending on user choice either at 30 or 60 FPS theoretically
I tested out my teapot demo plug-in in REAPER and Live on Windows 10 and still didn’t see any assertions. I think the problem is likely to do with some aspect of your plug-in’s configuration. Are you able to provide a minimal test case that demonstrates the problem?
Well I can’t or at least not now.
However I thought what could be involved here is that I’m instanciating GLTextures on both of my contexts. It seems to be the key to reproduce the bug because commenting out all the instanciations made on my “secondary” context made the assert disappear.
Maybe you should try adding another context and creating textures on it inside your teapot example?
Regards.
I’m wrong, this did not made the assertion disappear. I even tried to remove the “secondary” context and it still triggers.
Okay, I’ve spent the rest of my afternoon investigating and I’m going crazy because it just led me nowhere.
It happens on my project once I attach a context to any Component, nothing more. What is very strange is that it doesn’t happen if I create a new project with the projucer nor tweak the default AudioPlugin project after generating it with CMake to simply add a juce::OpenGLContext attribute, attach it in editor’s construction & detach it in editor’s destruction. I searched in my .jucer if I was able to find any specific config that would create the bug on my project but I wasn’t successful. Since I can’t share the code, I’ll just share a redacted callstack just in case it’ll speak to you :
The lines where there’s no text are line that points to an external routine. The component from which comes the CachedComponentImage that calls releaseResources is the editor, which is the component on which I’m calling attachTo.
Hope it will help… I’ll post if I have any updates on this topic.
Thanks for your time,
Regards.
