Tiling window manager implementation questions

[Jasper St. Pierre]

On Mon, Aug 4, 2014 at 8:16 PM, Michael Forney <mforney at mforney.org> wrote:

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

The solution we're going to say here is that a client should wait for a
configure event before attaching and committing its surface, and that
compositors should always send such an event immediately after
get_xdg_surface, even in normal, toplevel cases.

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)?
>

I don't understand this. The window manager and the compositor are in the
same process. Why do you need any synchronization here?


> 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>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140804/8541bea1/attachment.html>