On Fri Aug 23 11:16:48 2024 +0000, Alexandros Frantzis wrote:
Maybe it's a matter of avoiding unnecesary client window attach/detach
operations, I didn't try to be very careful about that. I guess it could help, but even if it does, it would just be a workaround for (what seems to me to be) a compositor issue. That being said, we may still want to do reduce attach/detach operations for efficiency rather than correctness reasons. In any case, I will try to chase this with upstream kwin.
Or can we also maybe detach buffers from the surface ourselves?
This is what I did to test my hypothesis for kwin, but I wouldn't want to have it there normally, because, like the `client->wl_surface` commit that we want to avoid, it can also lead to interleaving problems with GL/VK. If the worst case for this was just a transient visual glitch, perhaps it would be acceptable, but there are in fact scenarios where the compositor would disconnect us with a protocol error (see https://gitlab.freedesktop.org/mesa/mesa/-/blob/421c42170e1abda849ea19c07f61... and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/d1d185c61f68...).
Since this MR is now moving all client surface reconfiguration to the window thread, the chances of unfortunate interactions with the (possibly different) render thread (as discussed above) are increased. So, I would propose removing the `wl_surface_commit(client->wl_surface)` from `wayland_surface_reconfigure_client()`. The trade-off is that the client surface viewport will be applied at render time, which may increase sizing related artifacts when resizing and the GL/VK redraw is slow.
With the above, if an application resizes but doesn't render again the viewport will not be applied, but I think that's quite an edge case.