<div dir="ltr"><div>Hi,</div><div><br></div><div>I'd like to bring up two open questions about the implementation of a tiling compositor.</div><div><br></div><div>First, how should the initial size negotiation work between the compositor and a client? In swc/velox, I have been sending configure events to clients as soon as the wl_shell_surface/xdg_shell_surface gets created. This turned out to be problematic for mpv[0]. In that pull request, a comment by giselher made me wonder if this is acceptable behaviour for a compositor. With the ack_configure request from xdg_shell_surface, a compositor could wait until the first buffer is attached, then send a new configure event, and wait for the ack_configure before displaying that surface. However, this is probably not the best behaviour for something like a video player because the first couple frames may have been skipped. An alternative could be just clipping the surface temporarily, but that goes against the idea that every frame should be perfect.</div>
<div><br></div><div>Second, how should the compositor deal with a window manager which wants to change the size and position of a window rapidly in succession (for example, the window is moved from one monitor to another, and then to another)? My current idea is to send the configure event first, and then when the window manager attempts to move the window, wait until the configure event is acknowledged before actually moving the window. This creates an atomic transition from one tiled state to another. However, I wonder about the expected behaviour when the window is resized, then moved again before the second sized buffer is attached. When we do get the second buffer, if we leave the window in the initial position, or move it to the final position, it is of an incorrect size. So it seems like the best solution is to keep track of the positions the surface should be moved to in between resizes. However, this may be overcomplicating things. Additionally, it probably presents a suboptimal experience if one application is lagging, in which case all the other windows are in their correct positions, but one window jumps around the screens as it tries to catch up (if it is poorly implemented and does not process all configure events before resizing). Maybe it should be hidden until it acknowledges the latest configure? But then we run into the skipping frames problem again...</div>
<div><br></div><div>Any discussion is welcome!</div><div><br></div><div>[0]: <a href="https://github.com/mpv-player/mpv/pull/979">https://github.com/mpv-player/mpv/pull/979</a></div>-- <br>Michael Forney <<a href="mailto:mforney@mforney.org" target="_blank">mforney@mforney.org</a>>
</div>