It's the lack of network transparency which is the problem. No one's complaining about the overhead of it, because Wayland lacks this crucial feature.
Edit: Other features lacking in Wayland: A close button which works, consistent decoration across apps, efficient cut and paste, ... And things which Wayland has that are basically bugs: windows which are rotated at non-90 degree angles.
X violates it in every way possible. It has probably found a few ways of violating it that are not possible, and done it anyway. Wayland is a part of moving back to the roots. It will lack at least 95% of all the features X has, because they really, really shouldn't be implemented as a part of a huge, monolithic system that has to run as root. Instead, all those features should be their own libraries/daemons.
As such, Wayland will never understand networks the way X does. Which is good, because it shouldn't. Wayland will never do anything put pass OGL handles between processes, and do the last few stages of compositing, and forward input. It actually has a well defined scope, unlike the amorphous blob that is X.
Nothing stops you from implementing a network transport layer above Wayland. And somebody will. And since there is room for competing implementations, in less than two years, there will be better network display protocols than what X does. When you split huge, monolithic things into smaller parts with clearly defined interfaces between them, the parts themselves become easier to make.
> Other features lacking in Wayland:
- A close button which works
This is trivial. Just don't draw the close button with the application. Personally, I want my "close program" in a static place on the screen, so that's not a problem at all. If you want close buttons above windows, make the window manager put a small box it owns in the upper corner.
- consistent decoration across apps
When is the last time you tried to run apps from different toolkits on the same desktop? Notice that they look the same because it's implemented in the toolkit? X doesn't have consistent decorations across apps, and hasn't had them for a decade.
- efficient cut and paste
Why, oh why should that be part of the display server? Just why? Do you just want to pile all the features in the system into one big ball? And as for efficient, just how often do you cut and paste anyway?
Wayland lacks feature X is not a valid criticism against Wayland. Because that does not mean that a system using Wayland lacks feature X. And the primary feature of Wayland is that it implements as few features as possible.
In most circumstances I'm totally cool with accepting the superiority of the UNIX philosophy as an axiom, but I don't think I am in this particular case.
When it comes to "GUI stuff" I am a consumer. I don't care about better software engineering practices in my windowing system unless that means the experience will be better for me. So far I am not seeing that offered by Wayland, nor am I seeing any real evidence that better engineering would or could offer me a better experience. If this were still 1995 and battling X was still something I did then I'd be less inclined to ask for evidence, but these days X is simply something I only know that I use because it used to be a hassle. I haven't had to know about it for years, which I think is the way Windows and OSX work for their users.
The only direct advantage Wayland will bring is a flicker-free and tear-free desktop.
Wayland does giving out pointers to buffers, compositing, and input redirection. These all strongly depend on each other -- you cannot correctly redirect input without knowing the exact location of everything on the screen, you cannot composite without having access to the buffers. Any attempt to modularize the parts further would only lead to false independence -- no matter how you organize them, the parts are going to have to intimately know of each other to work.
A minimal Wayland implementation is "less than 1000 lines." I really cannot imagine what else could be cut from it.
Wayland does not do clipboards, rendering, fonts, networking, drivers, or anything else that makes the X server source tree be hundreds of megabytes.
X doesn't do clipboards, drivers, or fonts. Network transparency does not affect the code size. And the source tree is approximately 25 to 30 megabytes. It contains 7 different X servers (Xdmx, Xvfb, Xnest, Xquartz, Xwin, Kdrive and Xorg). The server you're talking about contains 6 megabytes of machine dependent code.
In fact, all the infrastructure that Wayland depends on is the infrastructure that X uses.
1st Bob: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers? Tom: Yes, yes that's right.
2nd Bob: Well then I just have to ask why can't the customers take them directly to the software people?
Tom: Well, I'll tell you why... because... engineers are not good at dealing with customers...
1st Bob: So you physically take the specs from the customer?
Tom: Well... No. My secretary does that... or they're faxed.
2nd Bob: So then you must physically bring them to the software people?
Tom: Well... No. ah sometimes.
1st Bob: What would you say you do here?
Tom: Look I already told you, I deal with the @#$% customers so the engineers don't have to. I have people skills! I am good at dealing with people, can't you understand that? WHAT THE HELL IS WRONG WITH YOU PEOPLE?!
We already tried the monolithic "everything you might want to make a GUI plus a few kitchen sinks transported over a network" approach to display servers. It didn't work out very well - it created a gigantic, bloated mess, with forward-looking extensions bolted on (composite) and deprecated ideas from the early 1990s clinging on for dear life (everything related to fonts).
There's no reason a networked layer can't be implemented on top of Wayland. Plus, because Wayland is simply a "dumb pipe"-style compositor, several network abstractions can be implemented and duke it out for supremacy: with Wayland, one could write a server which ships GL commands to the client (enabling leveraging the fast render path of the client's video hardware), a server which ships rasterized video (a la VNC), or even a server which implements drawing primitives a la X (or X itself)!
Wayland does not preclude the idea of network transparency. It simply builds the base level of abstraction on which network transparency can be built.
I'm never sure why something like 'screen' for X applications isn't standard (I suppose that is what VNC is..)
For instance, I personally prefer lower latency and ease of programming over network transparency. Your bottom might be my top ;)
It makes things much simpler.
Additionally, Nvidia doesn't need to support Wayland, that is why Wayland isn't using GLX by default.
You also have to weigh the utility of features. It may be that 90% of Linux desktop users would rather have fancy composting and a "cube effect" when doing fast user switching[1], but shouldn't network transparency win because it actually does something useful?
[1] See "Is Wayland replacing the X Server?" on http://wayland.freedesktop.org/faq.html#heading_toc_j_4
By providing a level of abstraction lower than that of X, Wayland provides a more flexible framework over which to implement whatever "long tail" of useful features the Linux community desires.
That's not very convincing. Assuming Wayland is successful, Xorg may vanish; that certainly seems to be what a lot of people are hoping.