We cannot integrate this into our event loop like we planned, because
Wine a) grabs the mouse pointer so we cannot do that, and b) blocks the
GUI thread. So instead we will spawn our own thread and do polling based
XDND. When Wine's tracker window gets destroyed, we know that the left
mouse button has been released.
Apparently X11 connections are a scarce resource, so it seems like a
good idea to not hang on to them for too long. Now this is sort of a
hybrid between COM-style memory management and a singleton.
Letting `std::unique_ptr<T>` do the thinking for us makes a lot more
sense. We only need manual memory management for the error because we
need to pass a pointer to that pointer to xcb, but at least we have the
macro there so it still stays nice and readable.
Some interaction between JUCE and Wine would cause these cursors to be
hidden and then never shown again. This is of course more of a temporary
workaround until the issue gets solved within Wine.
Instead of the parent Window. Tracktion Waveform does some weird things
with its VST2 editor embedding, so with the old approach this would
cause mouse clicks to be offset 27 pixels vertically and one pixel
horizontally.
Hopefully. Checking mapped state apparently wasn't enough to prevent
spurious assertion failures on `is_child_window_or_same()`. Now we'll
just use exceptions instead of assertions so we catch them and ignore
them.
This is probably a better idea than trying to be efficient. If we get
two events in a row, then it can be that the map status has changed
between the two events.
We did this before implementing the deferred close in yabridge 3.0.0. It
didn't seem necessary anymore so we got rid of it, but without this
closing an iZotope Rx plugin's editor in Renoise was guaranteed to
trigger an X11 error and crash Renoise. Doing this reparent doesn't seem
to cause any slowdown but it does at least fix the specific combination
of iZotope Rx and Renoise.
This is in some cases needed to get decent performance in REAPER, as
REAPER seems to query this information (which cannot change without the
plugin requesting a restart) four times per second.
In commit 9788f21e0e we changed the input
focus grabbing to only grab focus once per event cycle, because
otherwise Bitwig would fight over who was getting focus. This is a bit
hacky, and with this approach you could in theory still have an
unnecessary focus grab 60 times per second (i.e. the default event
polling rate). Now we instead check the current focus target, and only
request focus when it's actually necessary.
It's pretty hard to find a solution that checks all of the boxes. I want
something that:
- Closes instantly when you close the editor, and in REAPER you should
be able to instantly switch between docked and floating modes
- Where there should not be a delay in user interaction when quickly
reopening the editor (or doing that switching thing in REAPER since that's
the same thing)
- Where the window manager should not try to reparent the window during
the losing process as that can cause some jarring flickering
- And, of course, there should be no weird Wine X11Drv crashes
And it should do all of that in Bitwig, REAPER, Carla, Ardour and
Renoise. Apparently it's quite the task to find an approach that checks
all the boxes there.
On Bitwig grabbing input focus this way would trigger many more FocusIn
events, which in certain situations could cause the interface to hang
while everything was being processed.
This also changes the refresh rate for most plugins. You can now lower
this setting if your computer is struggling to keep up with rendering a
certain heavy plugin.
Although it hasn't shown up, this will get rid of the possibility of
off-thread effEditIdle calls causing issues. And since we need some way
to run call this function while the event loop is running anyways, doing
it entirely from a timer similar to how hosts on Windows would do it
seems like the best solution.
Before deferring closing the editor. This still gets rid of that issue
in Wine's X11drv that would result in a double destroy, and it also gets
rid of a delay that would still occur in Carla.
With the new deferred closing behaviour, closing the editor of Vital's
VST2 version would trigger an X11 error in Wine's X11drv. This doesn't
seem to happen with other plugins (or the VST3 version of Vital) and the
fact that this workaround even works is strange to say the least, but at
least it does work.
While this does get rid of artifacts, it can also add a brief moment
where the gray background becomes visible when the window reconfigures
which can look jarring.
This reverts commit 35c7138333.
I've also tried a lot of other things, but none of the solutions I've
tried work 100% of the time. It sounds like a better idea to have
something that doesn't work consistently than to have something that
inconsistently sort of works. Setting the size in `WM_WINDOWPOSCHANGING`
to (0, 0) fixes the drifting, but the mouse coordinates are still wrong
and `SetWindowPos()` breaks the reparenting.
This reverts commit db2cc5800a.
I think some rounding in Wine is causing this issue, but then again
we're not supposed to send these ConfigureNotify events to the window
directly anyways.
Robbert van der Helm