Hi all! I just ended the wildest debugging session which ended in the conclusion that Logic will under circumstances which are not entirely clear to me, not destroy the editor object when it is closed.
The editor continues to live - even renderOpenGL() is called while no editor is visible. When the editor is openened up again, newOpenGLContextCreated() is called, but never the destructor or constructor of the Component. This caused a lot of problems in my code, since shaders and stuff were not properly initialized at this point.
What’s more confusing is that I can provoke this behaviour by creating a “complicated” preset. Think an MSEG with thousands of control points will do the trick 99% of the time, while the simplest preset will trigger the issue hardly ever.
I’ve built a workaround so everything is reinitialized when the new context opens, but the entire situation leaves a bitter taste in my mouth. Is this normal behaviour?
Slightly related: Even on Intel, where AU plugins are not sandboxed I noticed that logic actually re-uses the very same memory when an editor is destroyed and re-created, I verified that by comparing the memory address of the editor when re-opening it multiple times. This might be related to Logic using its own malloc implementation.
This lead to a hard to track down uninitialized variable bug in one of our products recently, where the value of the uninitialized variable was always exactly the same as it was when the editor had been closed for the last time.
Ok so I didn’t lose my sanity after all. Thanks for confirming!
This is exactly what I thought at first when debugging my issue. Are you sure the editor got destroyed in your case? The outcome of variables “remembering” their values would be somewhat identical. This is true only for variables which aren’t initialized during construction of course as you say.
What you’re describing seems so familiar that I wouldn’t be surprised if the issues were the same in the end. But then who knows…
@TheWaveWarden Could you give me some insight into your workaround regarding initialization of OpenGL shaders?
I am currently dealing with the same issue you describe. I’ve got lots of custom OpenGL shaders. After closing the editor sometimes, the PluginEditor destructor will not be called. After this, reopening the editor will not call the PluginEditor constructor. In this state, my custom OpenGL UI appears black, while other JUCE-painted UI is fine. The OpenGL UI appears black because when the editor was reopened, the OpenGL thread pool in juce_OpenGLContext restarts and sends a openGLContextClosing() callback to all my GL components, so they get deallocated. But, since the constructor of PluginEditor is where I initialize my OpenGL shaders, etc., they never get recreated for this plugin open.
I wonder what location besides the constructor I should I be initializing my OpenGL shaders, etc?
I believe attachTo should not be called in newOpenGlContext created. I think it is fine to leave that in a constructor that is triggered from the main JUCE thread.
You just want to move any OpenGL-specific initialization into newOpenGLContextCreated such as shader code compilation, OpenGL specific allocations (glGenBuffers, glGenTextures, etc), initial uniform values. Then in openGLContextClosed you would deallocate any OpenGL data you reserved (glDeleteBuffer, etc).
Yes, it makes sense to leave that in the constructor as it is required only once.
But other than that I don’t really have anything in the constructor then except for setContinuousRepainting() , and still experiencing system instability warning on LogicPro.
Is it possible that setContinuousRepainting() is the culprit?
Note – if I remove attachTo() from component constructor, I do not get Logic warning!
Pardon my limited knowledge about openGL, I’ve just started getting hands on this!