I feel configure events and requests are messed up

[Kristian Høgsberg]

On Tue, Sep 6, 2011 at 4:11 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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!

Yup, what you describe below is how Wayland works now and I'm not
looking to change that part.

Kristian

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