I feel configure events and requests are messed up

[Kristian Høgsberg]

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.

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

Kristian