Tiling window manager implementation questions

[Michael Forney]

Hi,

I'd like to bring up two open questions about the implementation of a
tiling compositor.

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.

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...

Any discussion is welcome!

[0]: https://github.com/mpv-player/mpv/pull/979
-- 
Michael Forney <mforney at mforney.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140804/c30a92db/attachment.html>