I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno mar, 06/09/2011 alle 16.37 -0400, Kristian Høgsberg ha
scritto:
> 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.

Yes, this is the current state of Wayland, and I feel this is broken.
I don't understand why you consider it set in stone, considering that
the demo compositor so far has implemented very little to deal with
window management.

Giovanni

> 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
> >


-------------- 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/818c1977/attachment.pgp>