What's wrong with wayland?

[Sam Spilsbury]

On Mon, Feb 21, 2011 at 3:35 AM, Enrico Weigelt <weigelt at metux.de> wrote:
> * Marty Jack <martyj19 at comcast.net> schrieb:
>
>> If remote clients is your thing, instead of forecasting doom
>> because the old way may not work any more, first off, nothing
>> stops someone from writing a thing that listens on port 6000
>> and acts just like a remote X server only it is a Wayland
>> client, and second off,
>
> At this point, I fail to see the real benefit of Wayland, at
> least from user or infrastructure view. (yes, having the hw
> and composition part of the fat Xserver IMHO is a good thing
> from sw-architectural view).
>
> One thing that annoys me is that the current design papers
> explicitly take remoting out of the picture (almost declares
> that obsolete or tells people to use insufficient workarounds
> like VNC) and delegates a lot of things to individual clients
> (so in the end introducing massive code and data duplications).

It really isn't that complicated. Just make a "Netland" server which
manages your application's buffer and transmits it across the network
to the other Netland server which then fills the buffer on the client
machine. The whole reason remoting was taken out at the server level
is because these days it accounts for a lot of the overhead you'll get
with rendering, since the majority of clients will do all the surface
painting Client-side (cairo, Qt) or direct to the hardware (OpenGL).
For the case where the server and client are running on the same
hardware, this is advantageous since you can actually have smooth
rendering without round-tripping to the server all the time (which can
only do things such as lines, fills, arcs and bitmap fills, the latter
of which is used the most today). There isn't any way to describe
something like a "Gaussian blur" to the server, and trying to add such
things would only lead to an infinite expansion of the core protocol
to try and describe every new drawing operation that someone comes up
with.

The other reason why remoting at a server level has become more
useless is because people *are* choosing to use client-side rendering
libraries like cairo and Qt and just sending the bitmaps to the X
Server. In a network situation this drastically increases bandwidth
usage, rather than the relatively small bandwidth operations such as
lines, arcs and fills. So what we have now for networking is this
sub-optimal mix of both round-tripping a lot when we don't need to
(latency) /and/ high-bandwidth usage.

>
>> nothing stops someone from redesigning and rethinking what
>> the proper remote protocol is,
>
> I'd start with an proper model before starting to think about
> an specific protocol: why should a client still be responsible
> for drawing, instead of just describing what it wants to have
> displays (eg. an scene graph or something more hi-level) ?
>
> Typical GUI applications have concepts of windows (and windows
> within windows), widgets, etc. Those are all objects that can
> be described formally and rendered in a hi-level display server.
> This also would allow large savings of now heavily duplicated
> code and data in the individual clients.
>
> 8 1/2 could be a interesting conceptional starting point.

This is indeed the kind of remoting that could be achieved at a toolkit level.

>
>> using modern encryption and compression techniques and whatever
>> else is needed to get a VNC like solution that performs well
>> and is secure.
>
> VNC can not be done right that way, as it's conceptionally
> meant for a whole different purpose: it operates on screen level.
> It has no idea windows, server-side resource objects, etc.
> Simply lacks this information.

Indeed, VNC is a bandwidth hog and not really useful for different media types.

A good talk to watch on all of this remoting stuff is the talk that
Adam Jackson gave at LCA a few weeks ago [1], he's working on SPICE
and describes quite well all the different problems and solutions to
doing display remoting.

Regards,

Sam

[1] http://linuxconfau.blip.tv/file/4693225/

>
>
> cu
> --
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
>
>  phone:  +49 36207 519931  email: weigelt at metux.de
>  mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Sam Spilsbury