In WaveLab 9, macOS and Windows, I noticed that the openGL render thread in my plugin keeps running (I have continuous repainting enabled) even when the editor is closed and sucks up unnecessary CPU. In most other DAWs the editor is actually destroyed, but it seems like WaveLab just hides it. The odd thing though, is that
visibilityChanged doesn’t get called when the editor is “hidden” either, so I can’t catch it and manually turn off continuous repainting.
Has anybody else run into a similar issue?
We have run into this, there are a couple of hosts that don’t actually destroy the editor. You won’t get visibility changed messages because I believe those only apply when you call
setVisible() on the component itself, whereas the plugin editors are contained in wrapper components made by JUCE’s plugin format wrappers.
IIRC you may be able to check the real visibility status using something like:
bool isEditorShown(juce::AudioProcessorEditor &editor)
juce::Component *top = editor.getTopLevelComponent();
if (top == nullptr) return false; // just in case it's called while there's no parent
juce::ComponentPeer *peer = top->getPeer();
return (peer != nullptr && peer->isVisible() && !peer->isMinimised());
Thanks for the tip. However it looks like
ComponentPeer does not have a
Whoops! Sorry about that, I was going off of previous knowledge that’s now out of date Apparently there used to be a
juce::ComponentPeer::isVisible(), but looking back at older JUCE code (5.3.2 on my machine) it seems it always returned true…
You may have the possibility of casting
juce::ComponentPeer::getNativeHandle() and doing a platform-dependent check on whether or not that peer is visible, but I haven’t tried it myself to see how that works out in hosts…
For Windows it you would pass the
getNativeHandle() says it returns
WindowRef on OSX which seems to be out of date… it’s actually an
NSView* (looking at
juce_gui_basics/native/juce_mac_NSViewComponentPeer.mm), and you can use
Looks like we’ll have to update our own code for this as well…