Layer surface updated before corresponding ack_configure is committed

[wmww]

As per discussions in IRC, the correct sequence of events for changing anchor is:

1. Client set's new size and anchor
2. Client commits
3. Server does not move client on screen, instead it sends configure event. Even if it recieves more commits, it doesn't move the surface until the configure has been acked
4. Client attaches a correctly sized buffer and acks the configure
5. Only after receiving a commit after the ack_configure does the server move the surface

Currently rootston moves the surface after 2. I determined this by running the client in wayland-debug, and breaking on various messages.

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1657

[emersion]

Yes, rootston doesn't support pixel-perfect rendering for all operations. For instance, making a window fullscreen will result in bad frames too.

[arandomhuman]

This issue is in sway as well, unless it's fixed in master. I don't think it's a rootston/compositor issue, though.

Here's what the pipeline looks like, from what I've gathered. Let me know if I'm wrong. - client sets anchor (for example) - wlroots (handle_set_anchor) stores new value in client_pending - client commits surface - wlroots (surface_role_handle_commit) copies client_pending to current [1] - rootston uses current to arrange layers and configure multiple layers [2] - wlroots (send_configure) sends the configuration and stores it in server_pending [3] - client acks configure, attaches buffer, and commits surface - wlroots copies acked state to current

It seems like the state is being copied to current too early (in [1]). Ideally, it should be: client_pending -> server_pending (after commit; fixing [3], server_pending seems useless right now) -> configure_list (after compositor sends configure) -> acked_configure (by client) -> current (after commit). The compositor (in [2]) can't decide as of now whether to send a configure only, or to move as well.

Secondary issue: if the correct sequence is being followed, the compositor (in [3]) should only configure one layer at a time. It's easy to construct scenarios where otherwise it could get stuck in a never-ending loop with multiple layers.