I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 5:19 PM, Giovanni Campagna
> <scampa.giovanni at gmail.com> wrote:
> > 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.
> 
> Maybe you should introduce yourself and what you're working on before
> threatening to break protocol?  I don't know what you're trying to do.

Right, sorry, I should have done it before. Sorry also if my wording has
been strong so far, but my reading of the first reply was "it is better
like this, and we will never ever change it", even if X11 has done to
opposite for more than 20 years, with fairly good results (at least on
the management side).

Anyway, I'm working on porting Mutter to Wayland, and in various parts
the current X11 code base assumes that it can resize to whatever size it
likes, and that ConfigureRequests from other clients are just that,
requests, not orders.
There is a fair amount of code (dating back to previous century for a
big part) dealing with correctly sizing windows, in presence of
constraints, struts, particular user operations, etc. and the window
manager simply expects that windows won't get in the way (or if they do,
they do very clearly with WM_NORMAL_STATE, so the WM knows it).
For example, if the window won't maximize, Mutter will desensitize the
maximize item in the window menu and the maximize button in the title
bar, as well as not showing the light blue overlay when dragging to the
top, and same for edge tiling. All this is not possible if the final
decision is in the hands of clients, rather than the compositor.

> >> 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).
> 
> I think this is where some of the confusion comes from.  In Wayland,
> windows don't change size without the client being involved.  You
> can't meaningfully resize a window without the client rendering new
> content.  The compositor can draw an outline as it resizes the window
> and only send the configure event to the client once the resizing is
> done, but you can't render the window at a different size without the
> client providing the content.

Again, I think rendering a window has nothing to do with configuring a
window. You can stop updating the window in the compositor, but you need
some why to tell client and server state that the window size is
changed, even if the buffer is stale. Otherwise you're stuck with this
mess in which the real window size is taken from the size of the last
attached 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/20110907/02e5c825/attachment-0001.pgp>