Wayland Window Management Proposal

[Bill Spitzak]

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 remoting wayland compositor, which sends the window 
contents and update information to the real wayland compositor on the 
remote machine. The real one knows how to communicate with the remoting 
compositor.

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

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

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