http://wayland.freedesktop.org/architecture.html

This is really stupid and I hope this project fails like all the other "let's replace X!!!" masturbation in the 00s.

There is no evidence offered that involving the compositor in event handling is a performance problem in X (hint: like all the "X is slow because it is networked!" nonsense, it's probably not true). Even if that were true, this doesn't explain why the problem is better solved by starting from scratch rather than extending the Xcomposite extension.

But hey, let's write a new graphics system! We can get wonderful advantages like:

* Removing any hope of network transparency. After all, all I have is one computer and all I do with it is play videogames and watch porn.

* Come up with a new API! Everyone appreciates having to rewrite their libraries and applications to new and incompatible specifications.

* We need backwards-compatibility, so let's REIMPLEMENT ALL OF X! It will be really easy! And bug free!

* Old computers? Who wants to use those? Obviously we're not going to implement drivers for older hardware.

A tell-tale sign that this project is a dead-end is this statement: "rendering library such as OpenGL." OpenGL is not a rendering library, it's a specification. Just like the X protocol is a specification. If you don't understand why that's important, you shouldn't be trying to write a replacement for X.

-----

Ok, nevermind the "no network transparency" part:

"Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers."

http://wayland.freedesktop.org/

This actually looks somewhat reasonable.

(I wanted to post this addendum as a reply instead of editing because the points above characterize why most of the 00s X-replacement projects failed, but HN won't let me)

------

Another edit. This time quoting the FAQ (https://groups.google.com/group/wayland-display-server/web/f...):

"It's a minimal server that lets clients communicate GEM buffers and information about updates to those buffers to a compositor."

"Wayland doesn't get in the business of rendering, it expects the clients to use whatever means they prefer to render data into a GEM buffer and when it's done, inform the Wayland server of the new contents."

"Because we for the first time we have a realistic chance of not having to do that. It's entirely possible to incorporate the buffer exchange and update models the Wayland is built on into X. However, we have an option here of pushing X out of the hotpath between clients and the hardware and making it a compatibility option."

"The problem with X is that... it's X."

"No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients."

This is actually as stupid as I originally thought. Now I really, really want it to fail.