What's wrong with wayland?

[Mike Paquette]

On Apr 22, 2011, at 3:33 AM, Daniel Stone wrote:

> Hi,
> 
> On Thu, Apr 21, 2011 at 09:15:24PM +0200, Enrico Weigelt wrote:
>> * Sam Spilsbury <smspillaz at gmail.com> schrieb:
>>> 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.
> 
> Which leads to massive and unpredictable latency since you've now thrown
> a full vector rasteriser into your display server, so any window
> management, cursor movement, etc, operations will be blocked behind
> rendering which may run for an unbounded amount of time.
> 
> IOW, exactly what Wayland was (quite rightly) designed to avoid.
> 
> Cheers,
> Daniel

Quite correct, Daniel.  There once was a project called Display Postscript, which shipped as an adjunct for X servers.  It was also adapted as the window server for NeXTSTEP, and shipped for years on that platform.  The largest complaint from developers was the desirability for a client side drawing model which would not require describing content as vector data.  Developers found it difficult to manage a remote store of vector data that the server would manipulate.  There was also considerable overhead where raster data was needed for the window content, in managing and transferring the raster data to the server for rendering along with vector data.

For the Mac OS X project, a decision was made to deliberately redesign the server to be drawing model agnostic, allowing clients to draw to buffers (window backing stores) which would then be composited by the server as needed to produce screen content.   This produces a relatively lightweight window server that contains compositing (currently via software or OpenGL) of these buffers, event distribution and management, and display management.  Clients may draw using their favorite sets of APIs.  On Mac OS X that includes Carbon, the old school Macintosh QuickDraw based code, Cocoa, built on a Postscriptish vector + raster model, and the X protocol via a 'rootless' X server.

Mike Paquette
http://www.linkedin.com/in/michaelpaquette