Browse Source
VST3 Client: Make window sizing slightly more robust in Live
The following was observed for a VST3 plugin hosted in Live 11.1 with
auto-scaling disabled:
- It never calls setContentScaleFactor on the plugin's UI, so the
wrapper has to check the current display on a timer and update the
current scale factor when necessary.
- It calls canResize on the plugin view after opening it, but doesn't
seem to respect the result of this call. According to the VST3
documentation, a host is supposed to only call checkSizeConstraint
during a live resize operation (which should only happen if the plugin
reports it can resize), but Live calls this function every time the
user drags the editor. It also passes the result of this function to
onSize, whether or not checkSizeConstraints reported success.
- When dragging an editor between displays, Live will continue to call
checkSizeConstraint and onSize with the editor’s old size in physical
pixels. In some cases, JUCE's "scale factor check" timer callback
fires, resizes the view to the correct size, and then Live
asynchronously calls onSize again with the editor's old size in
physical pixels, resulting in the editor being set to the wrong
logical size.
This patch ensures that checkSizeConstraint always returns the current
size of a nonResizable editor. This means that the logical size of the
editor should not change when the result of checkSizeContraint is used
to resize the window.
pull/22/head