Wayland Window Management Proposal

[Michal Suchanek]

On 13 May 2011 19:45, Corbin Simpson <mostawesomedude at gmail.com> wrote:
> I was trying to stay out of this, but...
>
> On Fri, May 13, 2011 at 9:03 AM, Michal Suchanek <hramrach at centrum.cz> wrote:
>> This is *not* *about* *optimization*.  If you rely on *every* *single*
>> *client* to be responsive for your WM to work then the moment *any*
>> *single* *client* becomes unresponsive your WM *breaks*.
>>
>> If you think a non-broken WM is an optimization I guess we live in
>> somewhat different worlds.
>
> Strawman; it is always possible to multiplex I/O in a way that
> prevents any single client from blocking things being done in other
> clients or internal server work.
>

No, you can't if you bind the visible reaction to the input to some
operation potentially unbound in time - client update.

The user cannot figure out that the window is "virtually" resized and
the WM is waiting for client update if the on-screen window is still
the same size.

If the client takes, say, half a second to update which is completely
reasonable for a full re-layout and repaint of a window that normally
gets only partial updates then the resize will be *very* jerky, and if
the client is uploading a bitmap over network to update the window you
can't really avoid that.

You can make the compositor such that the bookkeeping required for
resizing a window in the compositor does not take long but you have no
guarantee that every client will do the same, and it's not even
possible for all clients to achieve.

If you take the client in a debugger example (or otherwise stopped
client) the window would resize only after the client is started
again, etc, etc.

Oh, and BTW we would not really need this debate if there was a
provision for replacing the compositor or window manager or whatever
but some time earlier it was suggested that it should be built into
the Wayland server and be so awesome that nobody will ever need to
replace it with a different one.

Thanks

Michal