I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno mar, 06/09/2011 alle 13.11 -0700, Bill Spitzak ha scritto:
> I believe that unless the client has final say, and an unambiguous 
> method to force a window to any dimension it wants, then Wayland is a 
> failure. Please do not copy the asynchronous window management of X11!
> 
> Here is what I see:
> 
> 1. There is a client->compositor call that says "resize this window to 
> here". It is obeyed UNCONDITIONALLY and the window ends up EXACTLY the 
> requested size. An actual resize of a window to a new size is done by a 
> client doing the following steps:

This is wrong. The compositor should not be required to obey any sizing
request from the client, it should apply its own policies first.

>    a. The client allocates an image buffer of the new size.
> 
>    b. The client draws the resized image into the buffer (including 
> window borders)
> 
>    c. The client tells the compositor about the new buffer and also 
> about the new resize request. Possibly this is merged into a single call 
> or Wayland does something to force atomic actions.
> 
>    d. The result is an INSTANTANEOUS (ie during the vertical retrace)
> change of the composited on-screen image from showing the old image at 
> the old size to the new image at the new size. THE USER NEVER NEVER 
> NEVER SEES A PARTIAL UPDATE! All pixels that were not in the window and 
> are now in the window change exactly once, from whatever they were 
> displaying before to the new resized image. There is no way to do this 
> unless the image is rendered already, no amount of "speed" can fix this, 
> you must have the image before the resize. Every pixel that was in the 
> window and now is not changes exactly once as well (this seems to be 
> less of a problem with X11 and Windows compositing).

You can do instantaneous updates even if the size is determined by the
compositor, rather than the client: you just wait for the client to
prepare a new buffer before redrawing the window.
Except that if the new buffer is not appropriately sized, you clip it
or transparently extend it to the new size.
Remember that the compositor decides at all times what goes on screen,
there is no point in letting clients specify sizes that compositors will
ignore (and yes, I'll break the protocol if needed to keep feature
parity with X11). My idea was just to make this clear at the protocol
layer.

> 2. There is a compostitor->client call that says "the user is trying to 
> resize the window to be like this". The compositor assumes the client 
> will respond with the above resize call, or something similar (ie the 
> client can fix the call to round the call the increments and aspect 
> ratios and any other rules it wants).

And this call is wrong. The compositor shouldn't ask, it should notify
that something is changed. Window sizes are server state, and should be
treated like that (including the possibility to change at any time).

> 
> 3. There is another client->compositor call that says "the user is 
> dragging the mouse and I have decided it is a window move/resize and I 
> want the compositor to take over and handle it". This allows the clients 
> to intercept every single possible click in the window without the 
> hideous complexity that is in X11 and Windows. This is because they 
> simply get every event first and can decide what to do. However this 
> allows the compositor to implement window snapping and preview, rather 
> than the clients having to do it. This gets I think about 100% of the 
> advantages of the X11 window managers.

Yes, and I did not propose to drop it, although I should be cleary
separated from the action of changing the window size programmatically.

> Please note that any scheme that does not allow the client to completely 
> render the new resized image before the window is resized is not 
> acceptable and violates Wayland's design requirements for flicker-free 
> update. Stop suggesting such things, PLEASE!

No. Rendering has nothing to do with managing windows, and if wayland
conflates these two things we have a fundamental design problem, that
may prevent usable window managers (as opposed to compositing managers).
You can stop rendering at any time to accomodate client lag, and
atomically replace contents, but the actual size of the window
(including decorations, that are server side) is changed immediately.
Btw, nothing of this really matters, as the majority of resizing clients
(as opposed to fullscreen movies or games) are perfectly able to render
in less than 1/60s.

> It looks like both the resize request and the compositor message can 
> have an xywh rectangle and four "edge" flags, and possibly a "title" 
> flags. The Wayland API xml document shows the edge flags but I have not 
> examined what they do, but as I see it they indicate whether a window 
> border is wanted on that edge. The "title" flag I would add to indicate 
> if a title is wanted (Windows-style maximize would turn off all the 
> edges but not the title, while full-screen would turn off the title too. 
> Tiling window managers would use these flags quite a bit. Clients would 
> be assumed to leave the window edges without borders at the requested 
> locations.)

No, as the protocol stands currently, the edge flag indicates which side
of the window was dragged, which is used to compute the new position of
the window (client side!) before drawing the new buffer.

Giovanni

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110906/fd6ee7a5/attachment-0001.pgp>