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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
