On Mon, Aug 4, 2014 at 8:16 PM, Michael Forney <[email protected]> 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 <[email protected]> > > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- Jasper
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
