What's wrong with wayland?

[Enrico Weigelt]

* Sam Spilsbury <smspillaz at gmail.com> schrieb:

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

A buffer of what exactly ?
Framebuffer ?

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

True for X11, but not neccessarily for a completely new approach.

> since the majority of clients will do all the surface painting Client-side
> (cairo, Qt) or direct to the hardware (OpenGL).

That's the main problem, IMHO. It leads to really a lot of unnecessary
code and data duplication. (btw: I'm glad to have all my systems free
of the Qt bloat ;-o).

Alternative: let the clients just _describe_ their window contents
as vector graphics, that only get manipulated when needed (and NOT
repainted over and over by the client itself!). Most of the common
widget toolkit's code (and runtime data) would be simply obsolete
this way.

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

Because X (which just happens to be the current standard) doesn't
provide high level functionality required todays. Doing this on
client-side is just a ugly workaround on a limited protocol.

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

Wayland doesn't even have anything like a network situation ...

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

Yes, but it still leaves the big bandwith/latency problems,
most notably the need for client-side repainting still in place.


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