Commit Graph

7 Commits

Author SHA1 Message Date
Aleksandr Mezin
90e3d9782d Revert "wayland/window: Correct detection whether to send configure"
It breaks more than it fixes.

After commit [1] Shell doesn't trigger the original issue [2] anymore.

[1]: ba0b9239d3
[2]: https://gitlab.gnome.org/GNOME/mutter/-/issues/1627

This reverts commit 236e9ec68f.

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1723

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1804>
2021-04-14 06:36:09 +00:00
Aleksandr Mezin
236e9ec68f wayland/window: Correct detection whether to send configure
When deciding if `configure` event should be sent,
`meta_window_wayland_move_resize_internal` compares requested window size
with `window->rect` size. However, `window->rect` is only updated when `commit`
is received. So the following sequence produces incorrect result:

1. a window initially has size `size1`
2. `move_resize_internal` is called with `size2`. `configure` is sent
3. `move_resize_internal` is called with `size1` to restore original size,
but `commit` for `size2` haven't arrived yet. So `window->rect` still has size
`size1`, and thus new `configure` is not sent
4. `commit` for `size2` arrives, window changes size to `size2`

Expected window size in the end: `size1`
Actual: `size2`

To fix the issue, take size from pending `configure` events into account.

Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1627

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755>
2021-03-12 16:25:10 +00:00
Jonas Ådahl
cda26b493e wayland: Only use async configured geometry if actually changed
When (un)maximizing, (un)fullscreening, the move/resize action is
flagged with 'ACTION_MOVE' and 'ACTION_RESIZE' , while e.g.
'appears-focus' does not.

When a client misbehaved and didn't immediately reply to a configure
request with a commit with the corresponding ack_configure, the
following commit would trigger a oddly timed move, making the window
appear to move back to a previous position.

Avoid this issue by only carrying over the target window position if the
configuration actually contained a new position.

We cannot only rely on the flags however, as e.g. a new position should
be respected during interactive resize, even though only 'ACTION_RESIZE'
is passed in such scenarios.

Do the same for the size, except if the window state dictates that the
size is fixed to a certain size, e.g. being fullscreen or maximized.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1445>
2021-01-30 09:49:13 +00:00
Jonas Ådahl
eaa6efef56 wayland/window: Don't lose precision in MetaWaylandWindowConfiguration
Commit 8bdd2aa7 would offset the window position by the difference
between the configured window size and the committed size from the
client to prevent the window from drifting while resizing.

This, however, did not take into account the actual geometry scale, so
when using any scale greater than 1, the window would rapidly drift away
due to that offset.

In order to solve this, we need to make sure we store away the pending
window configuration in the stage coordinate space, in order to not
loose precision. When we then calculate the offset given the result from
the client, it'll use the right scalars, while before, one scalar was in
surface coordinates, while the other in stage coordinates.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1490
2020-10-29 10:24:25 +01:00
Jonas Ådahl
6c82feb1b8 wayland/window-configuration: Track resize flags and gravity too
Will later be used to determine in what way a pending configuration will
resize.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
2020-02-29 21:01:50 +00:00
Jonas Ådahl
d22f947bf5 wayland/window: Pass popup configuration using relative coordinates
After popup placement rules have gone through the constraints engine has
ended up resulting in an actual move, pass the window configuration down
the path using relative coordinates, as that is what the next layer
(xdg-shell implementation) actually cares about.

In the future, this will also be helpful when the configured position is
not against the current state of the parent.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
2020-02-29 21:01:50 +00:00
Jonas Ådahl
554644f9e0 wayland: Rework asynchronous window configuration
This changes how asynchronous window configuration works. Prior to this
commit, it worked by MetaWindowWayland remembering the last
configuration it sent, then when the Wayland client got back to it, it
tried to figure out whether it was a acknowledgment of the configuration
or not, and finish the move. This failed if the client had acknowledged
a configuration older than the last one sent, and it had hacks to
somewhat deal with wl_shell's lack of configuration serial numbers.

This commits scraps that and makes the MetaWindowWayland take ownership
of sent configurations, including generating serial numbers. The
wl_shell implementation is changed to emulate serial numbers (assuming
each commit acknowledges the last sent configure event). Each
configuration sent to the client is kept around until the client one. At
this point, the position used for that particular configuration is used
when applying the acknowledged state, meaning cases where we have
already sent a new configuration when the client acknowledges a previous
one, we'll still use the correct position for the window.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
2019-12-09 10:09:40 +01:00