You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ignore spurious map-events on Wayland's wxGLCanvasEGL
In the recent changes for handling map/unmap events on Wayland's
wxGLCanvasEGL, we use the following GTK widget signals:
* The "map-event" signal to create the canvas's subsurface.
The earlier "map" signal can not be used, as the associated toplevel
window's Wayland surface may not yet exist by the time we receive it.
* The "unmap" signal to destroy the canvas's subsurface.
Using the later "unmap-event" signal is problematic, due to other
resources we build upon being already destroyed by then.
Usually, the "map-event" signal comes before "unmap" and resources are
created and destroyed appropriately. However, there's an edge case:
If a canvas is shown and then immediately hidden (before wxWidgets can
pump from the event loop), "unmap" will come before "map-event".
This happens because signals like "map" and "unmap" are delivered
immediately (when calling e.g. `gtk_widget_hide`), while signals like
"map-event" and "unmap-event" are delivered later on the event loop.
For the same reason, showing a canvas, then immediately hiding it, then
immediately showing it again, will cause two "map-event"s to get
delivered enqueued without a "unmap" in between.
This condition can be hit quite easily when setting up a complex UIs,
and in particular it is triggered by Aegisub during startup, leading to
a crash (Wayland protocol error) when opening a video later, or when
specifying a video directly on the startup command line.
To avoid this breaking our resource management, add some checks to detect
those "map-event"s we shouldn't handle - either the ones that happen
after "unmap", or the duplicate ones without an "unmap" in between.
See wxWidgets#23961, wxWidgets#23968.
(cherry picked from commit 133f773)
0 commit comments