Hi,
since JUCE 7 and commit c30b3a1 the outer wrapper component of a VST2 plugin editor is resized repeatedly from the VSTPluginWindow::timerCallback().
To me it looks like the problem is in juce_VSTPluginFormat.cpp, line 3268 where the size of the embeddedComponent is updated without checking if that’s actually necessary.
Wouldn’t it make sense to move that line inside of the if (! isWindowSizeCorrectForPlugin (w, h))block?
I’m unable to recreate a scenario where that function is called repeatedly. I’m using our AudioPluginHost on Windows and a JUCE VST2 plugin.
Do you see odd behaviour as a result of that call?
I can repeatedly catch this breakpoint when opening a VST2 editor window in the AudioPluginHost demo app. I have at least one HiDPI screen with a scaling > 150% attached, maybe that makes a difference…
We do not have an easy to reproduce bug in the demo app but in our host application scenario the updating of the plugin window bounds inside embeddedComponent.updateHWNDBounds(); triggers a dismiss message to all PopupMenus. Hence when a VST2 UI is open, all PopupMenus will get closed immediately after they have been opened.
You should be able to observe frequent calls to HWNDComponentPeer::windowShouldDismissModals() whenever a VST2 editor is shown as well.
The breakpoint is hit when an editor window is opened/closed or transitions to a monitor with a different scaling factor (I have two). This is expected. updateHWNDBounds() must be called every time a window change occurs otherwise DPI scaling gets a bit weird.
I would expect a loss of focus from a window state change to close most PopupMenus. I can have multiple VST plugins open within AudioPluginHost and have no problems with PopupMenu’s closing without input.
HWNDComponentPeer::windowShouldDismissModals() is a particularly busy function, and I expect to see many thousands of calls with typical use.
Do you see continuous calls to updateHWNDBounds() without any input to the window? As that doesn’t sound quite right. Other than that, however, everything else appears to be working as expected.
Yes, I see calls to updateHWNDBounds() right after opening the editor and it continues to be called without any user actions.
Looking at the callstack it’s pretty obvious why that happens: the function is called from the VSTPluginWindow::timerCallback() and the timer is never stopped. So I am quite irritated that you can’t see the breakpoint getting reached at timer intervals ~18ms 
Oh I see… maybe you have tested with VST2 plugins that respond to DPI changes? I do not have any of those in my list. But see checkPluginWindowSize(). It only forwards to resizeToFit() when pluginRespondsToDPIChanges == false.
That looks like it might be the case, sorry! I will do some digging!
Pushed a fix onto develop branch that fixes this issue. Thanks for letting us know about it.
Great, thanks for taking a look!
