This bug was introduced in b4c28db765.
The argument to contains() is in peer space (logical pixels relative to
the peer's top left). To convert to relative physical pixels, logical
pixels should be multiplied by the peer's scale factor, *not* divided.
258203706c introduced a problem where
live-resize of a window would cause the window content to flash and slow
down.
The cause of the errant behaviour seems to be that, during resize, many
WM_PAINT messages might be dispatched over the course of a single vblank
interval. Then, each of these paint calls was waiting for the next
vblank interval to display. This additional waiting resulted in
sluggishness, since many frames would have to be presented before the
presentation 'caught up' with the current window size. This also meant
that many consecutive frames were presented with stale window size
information.
The solution added here simply checks whether we're live resizing, and
uses the vblank instead of WM_PAINT to synchronise repaints during the
resize operation.
This fixes a bug where opening a foreground window could occasionally
prevent background windows from repainting. The symptom seems to be
caused by the system repeatedly sending WM_PAINT messages to the
foreground window and ignoring the background window. It seems that the
system will repeatedly call WM_PAINT until the entire region has been
validated - even if that region is null.
The COM interface functions use __stdcall, which can't be passed to a
function expecting a __thiscall function. This distinction is irrelevant
when compiling in x64 mode.
This commit partially reverts 07f801143c.
While it's justifiable that triggerClick() is guarded and ineffective
when the button is disabled, setToggleState() needs to work to correctly
represent the underlying parameter state.
By writing the data member into the pipe without serialisation, the
throughput between the main application and the WebView subprocess
increases from 0.7 MB/s to over 100 MB/s. Measured on a 2.2 GHz Intel
8th gen CPU in Debug build.
Previously, the MPEZoneLayout could only handle pitch-bend range
adjustments that ended with the MSB. If the final controller message was
the LSB, this resulted in the range being set as a 14-bit value, with a
value 128 times higher than intended.
D2D repaints are always driven by a vblank timer, and D2D presentation
can't happen any faster than the vblank callbacks, so I think it's safe
to remove the swapchain machinery and to rely entirely on the vblank
callbacks instead.
This issue could be observed when loading the WebViewPluginDemo in the
AudioPluginHost, opening its editor, and then attempting to close the
editor window using the titlebar button. Tested on Fedora 42 with
libwebkit2gtk-4.1.
Unloading the webkit library with dlclose seems to cause the webview
process to crash, even if gtk_main() has already exited at that point.
Maybe this points to a need to manually clean up the webview somehow
before calling gtk_main_quit, but I can't see any obvious candidate
functions in the docs (gtk_widget_destroy doesn't seem to help).
The workaround presented here just opens the webkit library with
RTLD_NODELETE, which isn't ideal but might be necessary if this library
hasn't been designed with dynamic load/unload in mind.
If the browser process happened to segfault, the old WIFEXITED check
would never succeed and the loop would never break.
The issue is resolved by additionally checking for other statuses that
also indicate that the child process is no longer alive.
Previously, on Linux, client plugin editors were embedded directly into the peer
displaying the client's AudioProcessorEditor.
Although this approach is simple and lightweight, it means that plugin
editors are able to reposition themselves over controls in the parent
window just by calling XMoveResizeWindow or similar on their own widget.
It's more desirable that the client editor should be clipped if it
attempts to draw outside the area of the AudioProcessorEditor.
