It seems that in a timerCallback (when i remove a GL-child) the Attachement::componentVisibilityChanged() arrives to late (this may happens in other kind of callbacks too).
So the component gets out of view, but the renderCallback still happens.
OK, try it again now.
Thanks, it fixes it. But i found another situation:
class OpenGLDemoTest : public Component, public Timer, public ChangeListener, public ChangeBroadcaster
{
public:
OpenGLDemoTest()
{
addAndMakeVisible(wrapper);
startTimer(1000);
addChangeListener(this);
};
~OpenGLDemoTest()
{
};
void timerCallback() override
{
sendChangeMessage();
};
void changeListenerCallback(ChangeBroadcaster*) override
{
if (wrapper.getParentComponent()==this)
{
removeAllChildren();
} else
{
addAndMakeVisible(wrapper);
};
};
void resized() override
{
wrapper.setBounds(0,0,getWidth()/2,getHeight()/2);
};
class Wrapper : public Component
{
public:
Wrapper()
{
addAndMakeVisible(demo1);
};
void resized() override
{
demo1.setBounds(0,0,getWidth(),getHeight());
};
OpenGLDemo demo1;
};
Wrapper wrapper;
};
};
// This static object will register this demo type in a global list of demos..
static JuceDemoType<OpenGLDemoClasses::OpenGLDemoTest> demo ("20 Graphics: OpenGL");
Thanks. And try yet again now!
I also consistently get these crashes on OS X.
So far I found that adding setVisible (false); in Component::removeFromDesktop() before deleting the peer solves the issue for VST and VST3, but not for AU where it seems that the window is getting hidden in a different way.
I’m suspecting that using CVDisplayLink would probably solve this as that’s what I see folks suggest in stackoverflow etc…
After some more investigation I think that I solved the issue. I opened an issue for this problem in JUCE’s bug tracker: https://github.com/julianstorer/JUCE/issues/88
Cheers, Yair
1 Like
I’m getting crashes in MaxMSP when deleting the vst~ object while the editor is open. It only happens if the GL context is attached, and only happens for the VST2 plugin. I’m detaching in the destructor. Below is the crash report from Max. If I’m debugging the plugin then it shows a bad access in CrBrowser. CrBrowser has something to do with CEF, which I know Max uses quite heavily. Any ideas?
11 com.cycling74.Max 0x000000010b98ab12 -[MaxCefApplication run] + 49
12 com.cycling74.chromium 0x000000010c5c4311 0x10c4a8000 + 1164049
13 com.cycling74.chromium 0x000000010c5c3c1c 0x10c4a8000 + 1162268
14 com.cycling74.chromium 0x000000010c6024d0 0x10c4a8000 + 1418448
15 com.cycling74.chromium 0x000000010c61b57a 0x10c4a8000 + 1521018
16 com.cycling74.chromium 0x000000010c601e6d 0x10c4a8000 + 1416813
17 com.cycling74.chromium 0x000000010c51a4b2 0x10c4a8000 + 468146
18 com.cycling74.Max 0x000000010b98ab20 -[MaxCefApplication run] + 63
19 com.cycling74.Max 0x000000010bad2175 juce::MessageManager::runDispatchLoop() + 81
20 com.cycling74.Max 0x000000010b9a3851 juce::JUCEApplication::main(juce::StringArray const&) + 59
21 com.cycling74.Max 0x000000010b9a3968 juce::JUCEApplication::main(int, char const**) + 68
It seems that the destructor for the plugin editor is never called.
Nor detachComponentFromWindowRefVST
Is this on the latest JUCE? We fixed a similar error quite recently.
Looks like the changes for this issue have caused a problem on Steinberg’s Wavelab under macOS. Can you guys who also had the crashes problem (@Chet_Gnegy @fiedleraudio @IvanC @chkn) check if you now have this new Wavelab problem? You can download a free trial version of “Wavelab Elements 9”…
The new problem manifests by OpenGL attachments not working, so your OpenGLRenderer doesn’t get to do your OpenGL drawings in Wavelab…
For anyone interested, I’ve implemented an alternative fix in SR’s branch which doesn’t cause problems in Wavelab. I’d definitely appreciate folks using it and thus testing it / offering feedback.
Cheers, Yair
Hi yairadix,
I still have this problem in Juce 4.3.1 Master. What exactly where the changes you made to get it to work?
Best,
Thomas
1 Like
We just refined the faulty assertion, but our fix also relies on our use of CVDisplayLink in macOS, which I’d recommend anyhow because it improves performance especially for several plugin windows open etc.
Hi yairadix,
thanks. If I use the master of Juce, which file(s) I would have to modify and how to make this work? I need this urgently because I am currently in the alpha phase of developing a plugin for mastering. So it is very important that it runs fine in Wavelab.
Thanks
Thomas
You can try using the SR branch and see if it works, or if you want minimal changes I think you’d need our changes in modules/juce_opengl, modules/juce_gui_basics/native/juce_mac_NSViewComponentPeer.mm, and modules/juce_gui_extra -
and it seems that in those files you’ll also get a bug fix related to OpenGL views with transforms, hope that’s ok…
Cheers, Yair
Ok, thanks. I will try the minimal changes version first.
Best,
Thomas
Hi Yair,
thanks, that solved the Wavelab issue. Works like a charm.
Best,
Thomas
1 Like
Good to know. Now ideally the fixes will be incorporated to main JUCE, otherwise when updating JUCE for other fixes you’ll need to merge the changes…
Sorry that this is still an issue. I can merge in this change into develop - but where are the CVDisplayLink changes?
I got recently some issues on Mac OS X at closure with an OpenGL app. The solution to solve them was to put a ScopedTryLock in the render function, and a ScopedLock in the destructor of the main component when the context must be detached