I feel configure events and requests are messed up
spitzak at gmail.com
Tue Sep 6 13:11:02 PDT 2011
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:
a. The client allocates an image buffer of the new size.
b. The client draws the resized image into the buffer (including
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
More information about the wayland-devel