For X11 clients running on Wayland, the actual texture is set by
Xwayland.
The shape, input and opaque regions, however are driven by X11
properties meaning that those may come at a different time than the
actual update of the content.
This results in black areas being visible at times on resize with
Xwayland clients.
To make sure we update all the regions at the same time the buffer is
updated, update the shape, input and opaque regions when the texture is
committed from when the Xwayland surface state is synchronized.
That fixes the remaining black areas being sometimes visible when
resizing client-side decorations windows on Xwayland.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
`meta_xwayland_surface_get_relative_coordinates()` may cause a crash if
the Xwayland surface has no window associated.
That can be observed when using drag and drop from an X11 window to a
Wayland native window:
```
at src/core/window.c:4503
at src/wayland/meta-xwayland-surface.c:200
at src/wayland/meta-wayland-surface.c:1517
at src/wayland/meta-wayland-pointer.c:1048
at src/wayland/meta-wayland-pointer.c:840
at src/wayland/meta-wayland-pointer.c:865
at src/wayland/meta-wayland-pointer.c:954
at src/wayland/meta-wayland-pointer.c:456
at src/wayland/meta-wayland-pointer.c:993
at src/wayland/meta-wayland-data-device.c:1004
at src/wayland/meta-wayland-data-device.c:1278
at src/wayland/meta-xwayland-dnd.c:326
```
Check if the xwayland surface has an associated MetaWindow prior to get
its buffer rect.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1073
There are two surface roles owning a MetaWindow: MetaWaylandShellSurface
(basis of MetaWaylandXdgToplevel, MetaWaylandXdgPopup,
MetaWaylandWlShellSurface, etc), and MetaXwaylandSurface.
With these two role types, the MetaWindow has two different types of
life times. With MetaWaylandShellSurface, the window is owned and
managed by the role itself, while with MetaXwaylandSurface, the
MetaWindow is tied to the X11 window, while the Wayland surface and its
role plays more the role of the backing rendering surface.
Before, for historical reasons, MetaWindow was part of
MetaWaylandSurface, even though just some roles used it, and before
'wayland: Untie MetaWindowXwayland lifetime from the wl_surface' had
equivalent life times as well. But since that commit, the management
changed. To not have the same fied in MetaWaylandSurface being managed
in such drastically different ways, rearrange it so that the roles that
has a MetaWindow themself manages it in the way it is meant to; meaning
MetaWaylandShellSurface practically owns it, while with Xwayland, the
existance of a MetaWindow is tracked via X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
The role determines how a relative coordinate is calculated. More
specifically, using clutters API to transform coordinates is only
accurate right after a clutter layout pass but this function is used
e.g. to deliver pointer motion events which can happen at any time. This
isn't a problem for Wayland clients since they don't control their
position, but X clients do and we'd be sending outdated coordinates if a
client is moving a window in response to motion events.
This was already done already, but now move the Xwayland specific logic
to the Xwayland surface role, keeping the generic transformation logic
in the generic actor surface role.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
