Tiling window manager implementation questions

[Jasper St. Pierre]

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

>
> On Mon, Aug 4, 2014 at 5:29 PM, Jasper St. Pierre <jstpierre at mecheye.net>
> wrote:
>>
>> 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?
>>
>
> Sorry, I misspoke. I meant "how should the window manager/compositor
> handle the case where a user moves a window to several different tiled
> configurations in rapid succession". Hopefully the rest of the paragraph
> makes sense with that in mind.
>

Ah. This is exactly the goal of the ack_configure request. When you send
out a configure event, you generate a serial and save it somewhere. When
you get the ack_configure request back, you know exactly which buffer
that's attached matches whichever configure event that you sent out.

If you wanted to be particularly fancy, you can save every position for
every move/resize operation, and replay that when you get the properly
tagged commit. That would be the most correct solution. However, you don't
need to be that fancy.

When you want to move/resize a window, save the position you wanted to move
the window to and serial that you sent out with the configure event. When
you get an ack that completes that pending move, update the window's
position.

The pathological case here, is, as you point out, an application lagging
behind. This simply might not ever happen in practice: the 16ms you have to
repaint your frame should be more than enough for every application. If
not, you don't have a new buffer to paint, only the old one, which means
you have two possibilities: show the old buffer at the old location, or
show the old buffer at the new location.

If you're that concerned about this, then some simple trial and error with
a hand-written pathological client that takes half a second after a
configure to redraw might provide some insight into which one of the two
alternatives looks better to a user.

And hey, since you're writing a tiling WM, you also don't have to deal with
the particularly tricky case of interactive resizing, in which the new
position of the window is resizing an edge based on the size of the new
buffer, which can't be calculated ahead of time. That's where a good part
of the complexity of the code in mutter and weston comes from.


> --
> Michael Forney <mforney at mforney.org>
>



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