Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:04 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Wayland - Beyond X (The H) by dlang
Parent article: Wayland - Beyond X (The H)

You really should read the Wayland protocol description before commenting on what needs to be in there. The sum total support for rendering in Wayland 0.85 is:

A mechanism to set up a shared buffer between the compositor and the client.
A mechanism to tie the contents of that shared buffer to an on-screen surface, possibly offset from the origin of the surface.
A mechanism to indicate to the compositor that a region of the shared buffer backing a surface has changed contents, and that the compositor should update the surface as presented to the user.
A mechanism for the compositor to use to tell the client that a new frame has been presented to the user, and thus it's worth creating new content.

Nothing in that precludes efficient remote operation - indeed, the damage events and buffer to surface attachment make a VNC-like protocol very easy to implement for any arbitrary Wayland client, including efficient support for scrolling.

The current plan, as laid out by the Wayland developers, though, is to expect the higher level toolkits (GTK+, Qt etc) to handle efficient remoting; they have much more detailed semantic views of what the user is trying to achieve, and (in theory at least) can do a much better job of minimising data transferred without compromising user experience.

to post comments

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:34 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

A VNC-like protocol is hopeless as soon as you encounter unusual rare and difficult operations like scrolling a surface. Oops, that's a massive damaged region and a massive bitmap copy.

A remote protocol in which you cannot scroll an xterm or a GIMP window at >5 refreshes/sec is essentially useless (that's what I see with VNC on a GbE LAN).

So remoting will clearly have to be done in the toolkits. Which means that toolkits that don't bother to implement their own remoting protocol will suddenly not be network-transparent anymore if you are using a Wayland server.

Joy.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 13:41 UTC (Wed) by farnz (subscriber, #17727) [Link]

Practically, I expect the following to happen if network transparency matters enough for people to put forward money (e.g. Red Hat telling its employees to make it happen for Red Hat's VDI product) or code (e.g. a lone developer who cares enough to work on it):

There will be a bridge client for Wayland that supports X11 protocol. Any toolkit that can efficiently remote over X11 will use this bridge at first.
The major toolkits (Qt, GTK+) will be ported to have an optional Wayland backend for local use only.
The major toolkits will acquire private remoting protocols that are optimized for their particular rendering usage, creating two competing NeWS-like systems, where the backends for the remoting protocols are written in the same languages used for the toolkits.
Some bright spark will spot that the private remoting protocols are fairly similar, and come up with a unified remoting protocol for both major toolkits, possibly even something NeWS-like but with a saner language for the server side widgetry.
Minor toolkits will pick up this remoting protocol as it's fairly simple to do so, and it satisfies the need for remote clients.

There's also a second plausible route for getting a network-transparent Wayland going:

Wayland clients adopt EGL en-masse as their accelerated local rendering API. Wayland clients either have no acceleration (they treat the display server as providing a dumb framebuffer, so no display server can remote them efficiently), or they use OpenGL and EGL to render.
Someone produces a virtual GPU intended for the VM situation, where GPU commands are serialised in and out of the VM, and implements a Mesa driver for it.
Someone adapts that virtual GPU, so that the serialisation protocol works well over a network.
The obvious combination of networked virtual GPU and Wayland protocol is defined for running over a network connection.

This second route has one advantage; there are multiple groups who would like an efficient virtual GPU, and so there's likely to be more manpower available for it.