-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VST3 in Ardour on Linux - resizing fix #867
Conversation
Adding host specific workarounds is not the never a good approach. According to https://steinbergmedia.github.io/vst3_doc/base/classSteinberg_1_1IPlugView.html#a3e741e55c2c047a4cc10f102661f5654 the plugin should instead request a resize (IPlugFrame::resizeView ()), the host then resizes the window and acknowledges it by calling onSize afterward. -- JUCE should not call back to the host/OS managed window from the Why is |
I agree a host specific workaround is far from ideal. But hey there's already a Cubase10-on-mac workaround a couple of lines above, why not add a few more! I did a bit of reading on the ComponentPeer:
I don't understand why a plugin would need to manage the window with any host or OS. I'll test some plugins across a few different hosts and OS's with this updateBounds call removed and see if it causes any issues... Update: Linux:Removing updateBounds on my plugin didn't cause any noticeable problems in:
Mac:Again, no noticeable problems with the updateBounds call removed when running a simple JUCE plugin in:
I can see why the ComponentPeer would be required in the standalone app that needs to manage the window itself, but not sure why it's needed for a plugin. |
I'm not opposed to also work around this on the Ardour side of things, but I'd like to understand this first. |
I've tried this out in a debugger, and I can reproduce the issue where Ardour repeatedly calls The docs for
I'd interpret this to mean that the implementation of Elsewhere on the same docs page, it says:
Again, this suggests that any native view resizing should happen inside the Looking at what VSTGUI does, it seems like the editor checks whether the requested size is the same as the current size, and exits early in this case. Adding a similar check to JUCE's Linux ComponentPeer, to bypass setting the window's size if it already has the correct size, seems to fix the infinite resize loop in Ardour. We'll update JUCE with this change. On a related note, I'm not convinced that Ardour is completely correct here. When it gets stuck in the resize loop, I can see it making alternating calls to
|
On 3/11/21 5:50 PM, reuk wrote:
Perhaps Ardour should avoid calling `onSize` if the plugin is already using the correct size.
Yes, we're considering this as well.
|
@reuk Why does this only happen on Linux? |
I'm guessing it's due to this: JUCE/modules/juce_gui_basics/native/juce_win32_Windowing.cpp Lines 1483 to 1493 in 85899f8
If the size/position hasn't changed, we set |
Skip call to onSize() when the plugin's size already matches. #599 juce-framework/JUCE#867 https://discourse.ardour.org/t/sonobus-vst3-gui-hogs-cpu-only-when-ran-inside-ardour-on-linux-but-not-windows/105573
I should point out that @x42's commit does not prevent all resize loops. I just tested this fix and I was easily able to create a resize loop even with the size-changed check. It prevents the initial resize loop when opening the plugin UI, but try resizing the window a bit and you'll easily trigger a loop. I added print statements to both of the
So, now it seems to be stuck in some kind of alternating resize loop. Or the plugin is not reporting its size as equal to what Ardour thought it had changed it to, so the "has-the-size-changed?" check always results in the answer "the-size-has-changed". So far the only stable way for me to run a JUCE plugin in Ardour is to remove the Thank you all for helping to solve this! |
I think this issue should be resolved by this commit: d4e8020 Please could you check whether this patch resolves the issues you were seeing? |
@reuk yes this commit does the trick!!! Thank you everyone! |
Hi JUCE team, I believe this PR fixes resize loop issues I have been experiencing trying to build VST3 plugins on Linux to run in Ardour.
Initially I took a look at the Ardour VST3 host code to see if there was an issue there. That lead to this PR, but upon further digging I found that JUCE's call to
updateBounds
on the ComponentPeer seems to be interfering with Ardour's own window resizing. It seems like JUCE is trying to modify the plugin window size directly during theonSize
callback, while the VST3 spec indicates that the host should handle window resizing.Prior to this change, any resizable JUCE plugin causes huge performance issues in Ardour (Linux) when the GUI is opened and immediately enters a resize loop. It's not usable at all. After the change is applied, the plugin UI behaves fine and everything seems stable.