Wayland Window Management Proposal

[Michal Suchanek]

On 16 May 2011 23:13, Bill Spitzak <spitzak at gmail.com> wrote:
> Michal Suchanek wrote:
>
>> 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.
>
> My understanding is the exact opposite: the compositor is *VERY* aware of
> remote windows, as it is it's job to do the remoting. A client connects to a

Then point me to any place where it does any remoting.

> remoting wayland compositor, which sends the window contents and update

What is this "remoting compositor"? A proxy that allows remote clients
to connect to Wayland on other system?

> information to the real wayland compositor on the remote machine. The real
> one knows how to communicate with the remoting compositor.

The proxy is just a plain client, how does the local Wayland tell it's a proxy?

>
>> 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.
>
> My tests show that update can be much slower than this and still appear
> "smooth". The important thing is that the contents update in exact lock-step
> with the border and never flash, but rates as slow as 5fps look quite
> smooth. This can be seen in some X media players that do both double
> buffering and client-side decoration.

It is still in the same ballpark - fractions of second. And would
probably depend on the user.

>
>> 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).
>
> The Wayland client will send an indication that it responded to the resize
> request, so the compositor will know this happened, even if the client
> decided not to change the window size. It is also the client's
> responsibility to initiate the resize, so it can just skip this if it knows
> it is not resizable.
>
>> 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.
>
> Comparing compiz and old X, this looks worse to me. It looks best to just
> have all the new window area contain whatever pixels were there before (ie
> the intersection of the old and new window, surrounded by pixels from other
> windows, old window borders, etc). The reason is that the pixels only change
> once, from old contents to new contents. Putting anything else there makes
> them change twice, from old to temporary to new contents.

And what's the problem if the difference between the replacement
content and the actual content is small and very unlikely to be
noticed?

Anyway, there is not only look but also feel of the environment. You
are obsessed with the window looking pixel-correct. However, for the
feel to be smooth the window must quickly react to user action. If
mouse resizes are implemented this is one of the few places where many
user actions happen in quick succession. The drag action results in
lots of small resizes and all of these have to happen fast. Otherwise
the UI appears laggy or worse, the user gets lost because the screen
content does not correspond to the actual state - window sizes.

>
>>> 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...
>
> I think the wayland compositor could track how long the clients take to
> respond to events. They would only disable if they suddenly took several
> times longer than before. If the recorded lag exceeds a threshold the
> compositor could resort to rubber-band resize.
>

No way. This must be a hard limit on the compositor side so that the
UI works reasonably at all times. It should be configurable by the
user but not the client applications.

Thanks

Michal