These functions have had a UI thread requirement added after VST 3.7.7.
This change may cause some breakage because of the mutual recursion
requirements.
I decided to not do this for most of the simpler getter-style functions
that the VST3 specification now for some reason requires to be called
from the UI thread, as this could significantly hurt performance and
changing this is more likely to cause problems than leaving it alone is.
DMG Audio Compassion has a expand/contract toggle button that adds a new
section below the main GUI. Without SWP_NOMOVE it would most of the time
fail to expand and the parent_window_ would sometimes fail to resize
accordingly if the expansion/contraction succeeded resulting in the GUI
locking up.
SWP_NOOWNERZORDER is the same as SWP_NOREPOSITION so having them both
was redundant.
Adds timer_proc lambda for VST3 to check for size mismatches and trigger
a new resize to correct it through eventual consistency.
This is done to workaround an X11 sync issue where the plugin view would
end up smaller or larger than its wrapper window. In Ardour this could
result in the plugin becoming uninteractable.
Once we get a single absolute ConfigureNotify event, we assume they will
keep coming and ignore any relative ones. The relative computation only
works if the parent window is a direct descendant of the host window,
which may not be the case.
To fully fix this in the general case (only relative ConfigureNotify
events) we would have to walk the window hierarchy and add up all the
offsets until the host window, but so far the only known case of an
extra level (Ardour VST2) also sends absolute ConfigureNotify events, so
we can just use those.
For VST2 in Ardour, it seems Ardour is doing its own WM/wrapper window
thing too. In this case, the plugin gets absolute ConfigureNotify events
that are already in the root coordinate space, so just use those
coordinates and ignore the host window.
Also fix the dimensions, which should always be those of the parent
window, not the host window. If the parent is the host window, still
track its geometry separately, and just don't add in the host window
dimensions in this case either.
Sometimes the plugin size might be off-by-one due to HiDPI scaling. If
so, pretend it's actually the size that was requested, to avoid ending
up in an infinite loop.
Ardour brings up the plugin UI before the host window is visible, and it
is missing some properties. Using WM_WINDOW_ROLE instead of WM_STATE
makes it work.
For reference, these are the properties that are set on the window at
the time of plugin GUI instantiation:
_NET_WM_ICON(CARDINAL) = Icon (16 x 16):
WM_WINDOW_ROLE(STRING) = "plugin_ui"
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 6294918
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x600d85
WM_CLIENT_LEADER(WINDOW): window id # 0x600001
_NET_WM_PID(CARDINAL) = 1604801
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "homura"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 521 by 46
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "ardour-8.12.0", "Ardour-8.12.0"
WM_ICON_NAME(STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
_NET_WM_ICON_NAME(UTF8_STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
WM_NAME(STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
_NET_WM_NAME(UTF8_STRING) = "Audio 1: Melodyne (by Celemony) [VST3]"
We just need this constant, so there's no real need to add the
additional dependency. There's also no real harm in adding it, but it
would result in additional work for every packager.
Robbert van der Helm