latest tip, latest VST SDK, VST2 (not VST3), Mac El Captian, 64bit, Cubase 8
JUCE Demo Plugin
Not sure if its maybe a specific Cubase issue
A part of the GUI will be permantly redrawed (but only the first 4 top pixels, as it looks like)
Looks no repaint()-call involved
r NSRect (origin = (x = 0, y = 0), size = (width = 404, height = 4))
#0 0x0000000128973334 in juce::JuceNSViewClass::drawRect(objc_object*, objc_selector*, CGRect) at JUCE/modules/juce_gui_basics/native/juce_mac_NSViewComponentPeer.mm:1530
#1 0x00007fff8a60abd6 in -[NSView _drawRect:clip:] ()
#2 0x00007fff8a607d21 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#3 0x00007fff8a6031ef in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#4 0x00007fff8a5bd971 in -[NSView displayIfNeeded] ()
#5 0x000000012897daf0 in juce::NSViewComponentPeer::performAnyPendingRepaintsNow() at JUCE/modules/juce_gui_basics/native/juce_mac_NSViewComponentPeer.mm:1267
#6 0x0000000128a05438 in JuceVSTWrapper::doIdleCallback() at JUCE/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp:1351
#7 0x0000000128a0087a in JuceVSTWrapper::dispatcher(int, int, long long, void*, float) at JUCE/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp:1437
#8 0x00000001289fde19 in AudioEffect::dispatchEffectClass(AEffect*, int, int, long long, void*, float) at thirdPartySDKs/vstsdk3/public.sdk/source/vst2.x/audioeffect.cpp:54
Haven’t checked but I remember the bottom being redrawn permanently as Cubase shows rounded corners at the bottom, and therefore uses a transperent window for the plugin. It should disappear if you toggle Cubase’s “always show plugin window” (or similar) option for the plugin.
Same thing in reaper (can be easily seen with the juceDemoPlugin and JUCE_ENABLE_REPAINT_DEBUGGING)
the vst2 got a line at the bottom (with a height of 3 pixels) which is continuously repainted.
This stops if you resize the reaper's window in which you have the plugin.
This restarts if you resize the plugin gui through the juce resizer corner.
I have this issue too. It triggers repaint() of the main component and paintEntireComponent in my case. Why does this trigger a repaint of all components? Is it possible to avoid this?
Call stack looks like this:
0 0x0bd94769 in GraphicHelper::drawRect(juce::Graphics&, float, float, f
1 0x0bd7e46b in TalScalableComponent::paint(juce::Graphics&) at TalCompo
2 0x0bb78d11 in juce::Component::paintComponentAndChildren(juce::Graphic
3 0x0bb78bd5 in juce::Component::paintEntireComponent(juce::Graphics&, b
4 0x0bb786c2 in juce::Component::paintWithinParentContext(juce::Graphics
5 0x0bb78e73 in juce::Component::paintComponentAndChildren(juce::Graphic
6 0x0bb78bd5 in juce::Component::paintEntireComponent(juce::Graphics&, b
7 0x0bb786c2 in juce::Component::paintWithinParentContext(juce::Graphics
8 0x0bb79065 in juce::Component::paintComponentAndChildren(juce::Graphic
9 0x0bb78bd5 in juce::Component::paintEntireComponent(juce::Graphics&, b
10 0x0bc2eb28 in juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsC
11 0x0bcb4af0 in juce::NSViewComponentPeer::drawRect(_NSRect) at JuceLibr
12 0x0bcb2657 in juce::JuceNSViewClass::drawRect(objc_object*, objc_selec
13 0x97ad1160 in -[NSView drawRect:clip:] ()
14 0x97acfa8f in -[NSView recursiveDisplayRectIfNeededIgnoringOpacity:is
15 0x97acc826 in -[NSView displayRectIgnoringOpacity:isVisibleRect:rectI
16 0x97ac7917 in -[NSView displayIfNeeded] ()
17 0x0bcbd7aa in juce::NSViewComponentPeer::performAnyPendingRepaintsNow(
18 0x0bd4fb46 in JuceVSTWrapper::doIdleCallback() at JuceLibraryCode/modu
19 0x0bd4b951 in JuceVSTWrapper::dispatcher(int, int, int, void*, float)
20 0x0bd48fab in AudioEffect::dispatchEffectClass(AEffect*, int, int, int
21 0x0023ea57 in VST_HostedPlugin::CfgProc(HWND*, unsigned int, unsigne
22 0x0023a59f in VST_HostedPlugin::CfgProc(HWND*, unsigned int, unsign
It maybe have something to do with USE_COREGRAPHICS_RENDERING , but i’m not sure what this flag means…
This one is a pain and i think there is no solution for this. It seems that already an empty UI slows down the whole UI thread if you open around 8 instances in reaper (if you open the plugin in its own windows). Same happens in cubase. Even if repaint() is not called. Only changing the size of the reaper window manually and make it around 10 pixels bigger solves the problem (Corner size as mentioned above).
this is really bothering me too. @patrickkunz did you find any other tricks/way to solve that since then? Or that is definitely something to be fixed on the host (cockos) side?
I noticed that the margin around AU plugins in reaper is always around 10 pixels. VST plugins don’t have any margin border. It would fix the issue if VST plugins also have a margin border around 10 pixels. It should be possible that the host give that extra space for VST’s like he does for AU’s. As we already know does the problem disappear when you manually make the reaper window around 10 pixels bigger. Would be great to see a solution on the host side for this.
We’re also experiencing this issue on Ableton Live - the bottom few pixels of the VST are constantly redrawing. The behavior is also present in Cubase and Reaper. Really annoying, but it seems that there’s no workaround?
The VST wrapper is constantly calling the ComponentPeer function performAnyPendingRepaintsNow() (juce_VST_Wrapper.cpp line 1331), which is what is triggering these repaints. However, I notice this call doesn’t happen in either the AAX or AU wrapper, is there a reason this is only called in the VST wrapper? Commenting it out solves the issue, but I’m sure it’s there for good reason (maybe VST doesn’t have control of the event loop)?
TBH it might be something we could remove now - it used to be necessary because old hosts would block the message thread while the user was dragging things in the host’s UI, which meant that our plugins wouldn’t be able to repaint at the same time without using this mechanism. IIRC the VSTGUI code used the same system.
But any host written in the last few years is almost certainly not going to work like that - might be worth us ditching this now…
I think we might remove it here…we’d rather see smoother drawing in a greater majority of cases. That being said, I’d be curious to know more precisely when hosts stopped exhibiting this blocking behavior. We’ll have to do some testing here.
It dates back to the old Carbon days, when some hosts would use the old modal TrackMouse stuff. I don’t think any Cocoa app would have a problem if it was removed.
I’ve been testing JUCE plug-ins and removing the editor idle callback seems to be safe. There’s a comment about WaveLab being problematic, but if that also turns out to be fine and there are no objections on this thread then I’ll make this change in the next couple of days.
