Wayland Window Management Proposal

[Michal Suchanek]

On 16 May 2011 16:17, Solerman Kaplon <solerman at gmail.com> wrote:
> Em 13-05-2011 15:38, Michal Suchanek escreveu:
>>
>> 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.
>
> That's why Windows server disable repaint's on windows resize by default
> when running over a network. It's just sends the final resize to the window
> and you get partial screen updates all the way to it. Users seems to not be
> really annoyed by it really.

The thing is that in Wayland the server is not aware of any remote vs
local windows. Remote applications are in no way part of the protocol
and will supposedly sneak in later by means of some remoting proxy.

Also there are local sources of lag like applications that are low
priority, busy, swapped out, poorly written, etc.

This is something that a decent desktop must deal with.

>
>> 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.
>
> I think current resize in X is good enough. If you are using a debugger, you
> ain't any kind of "normal" user who can't understand that if you pause all
> threads in the debugger you going to hang screen drawing for that app at the
> same time.

Well, the whole thread is about the fact that many people here think it is not.

On 14 May 2011 01:48, Bill Spitzak <spitzak at gmail.com> wrote:
> Michal Suchanek wrote:
>
>> It may be rubber-band or it may be some other effect but either way
>> you need something to draw on the screen until the client performs the
>> update which will draw a "not fully updated window" in case the client
>> does not update fast enough and by some is "unacceptable in wayland".
>
> A rubber band resize is part of the window management design and is not a
> partial update, any more than the mouse cursor atop a window means it is not
> fully updated. The image is fully expected to appear when the user drags the
> mouse.
>
> A rubber band that appears after a timeout when it detects the client is
> locked up is what you say, as the user will see an image that they would not
> see if the client was responsive. However there is nothing wrong with wrong
> images when the compositor detects that the client is not responding. What
> is necessary however is that a client that reacts within a timeout will
> never display a partially updated image.

I guess that this is something that can accommodate both client that
repaint in time to have smooth resizes and imperfect clients that
require workaround in the compositor for the resizes to appear smooth.

As a technical detail since vrefresh is the point when the screen
should be updated, it typically happens 50-60times per second and
seemingly smooth movement requires about 25fps at the very least the
timeout for the compositor to start drawing some replacement should be
at most some 2-3 vrefresh intervals. This is something that can be
communicated to the client so that it is well aware when it lags.

The client, however, must communicate to the wayland window manager
the resizability of its window so that the windowmanager can tell
apart clients that lag and clients that plain refuse to resize because
they rely on the window being fixed size (yuck).

If the replacement is the last window content stretched to the new
size and slightly blurred then the distortion might not be noticable
even for clients that take slightly longer but not too long. For even
less cooperative clients the "rubberband" or full window with some
generic "stoned" image would be required. There is room for user
preferences here for sure.

On 14 May 2011 12:09, maledetto <maledetto at online.de> wrote:
> The only *generally acceptable* way to manage lags in communication I
> see is that the server *fades-out* the window in question to signal that
> the client is unresponsive and waits for it to respond in a time before
> the kill-dialog appears. This is a good standard that doesn't need
> hacks or special effects and doesn't paint nonsense on screen.

I don't think a client needs to be responsive at all times. It only
needs to be responsive at times when a response is required, at other
times it can do nothing at all and it's fine.

eg. a window resize to be completed properly requires the client to
submit a buffer of the new size so that the compositor has some
content that it can paint in the new resized window. However, when the
compositor decides to hide a window (eg. to switch virtual desktops)
the client should be informed but no action is necessarily required on
the client's part. If the client is displaying, say, a status
information of some sort it may stop updating it now but if the
information is not changing in the first place (like the current date
which changes only once per day) it need not do anything until it
receives user input or its timer expires.

>
> On the other hand, some apps always lag behind and probably should be
> allowed to do so if they are very important to the user. The question
> is how. Possibly this could be *configured* via a special effect-plugin
> that manages single or all windows different to the default setting.
> This is like *theme'ing* those problematic issues ;) At least it allows
> the server to follow a strict default mode without forbidding the user
> to decide differently...

Yes, a debug mode which flashes the window every time it lags might be
also useful ;-)

Thanks

Michal