On Tue Oct 10 12:47:30 2023 +0000, Alexandros Frantzis wrote:
I experimented a bit with `visible_rect` as a method to handle the overshooting situation, and I am not convinced that such a change is worth it at the moment. My first observation is that, as you describe, using `visible_rect` actually crops the content, whereas setting the xdg geometry maintains the whole content but helps the compositor figure out how to position it properly. Thus the geometry method better matches the winex11 behavior in this case (but perhaps we don't care to replicate this?). FWIW, we could also tell the compositor to crop if we prefer (using `wp_viewporter`). The second observation is that to use `visible_rect` we will need to make a decision about the cropping based on the window config, whereas the geometry acts based on the latest current surface config, which is what we actually want to respect. This removal of the logic from the point it's actually needed makes it harder (for me, at least) to reason about the overall correctness. Perhaps when we will want to support server-side decorations we will have to go down this path, but there are also other alternatives (e.g., telling the compositor to crop instead).
to detect fullscreen windows is the visible_rect, which is actually
different from the window_rect that this call returns. Since, at the moment, I am not touching `visible_rect` (which implies `visible_rect == window_rect`) I am just using `window_rect` for everything. But I can switch to explicitly storing and using `visible_rect` (without changing it) if you think that's clearer.
I think passing the rectangle from `WindowPosChanged` would be better and avoid any confusion about the state of the window rect and is validity when we are querying it, as well as when this `wayland_window_config` can get updated (and also making it slightly more similar to `winex11`).