There are many myths regarding Wayland. One of them is that somehow it will lead to increased performance, because it removes the server-client model.
Wayland really is just about cutting out the cruft. Nowhere does it force any Windows design on the user in any way that X does not. People who don't understand much about X or Wayland (i.e. you) tend to associate the idea that Wayland prefers client-side window decorations with a ton of problems in Windows. Basically, you are associating a particular implementation with a general idea, which is silly. Windows apps don't lock up the desktop because they use client-side decorations (and, in fact, they don't lock up the desktop ever at all in Windows 7, despite still using client-side decorations).
Besides that, GTK+ and Qt already started adding client-side decorations long before Wayland started. And many popular X apps have used client-side decorations for well over a decade, including such olden popular apps like XMMS and modern popular apps like Google Chrome.
Client-side decorations fix a TON of problems that are unfixable in the traditional X model of having a separate app draw decorations. Totally broken things like out-of-sync rendering, inextensible window border contents (and hence tons of wasted space), and poor integration between the content and the chrome.
It's worth noting that client-side decorations do NOT mean client-side window management! Many of the Windows XP bugs (which is a non-composited desktop, I might note) related to window management would not exist on Wayland with client-side windows.
As a final point, nothing in Wayland actually _forces_ client-side windows. It's just that Wayland is written optimized for that case, unlike X which isn't optimized for anything. Running a window-manager and a compositor that does server-side decorations is every bit as possible in Wayland as it is in X, it just isn't something anybody's bothering to do because anybody who actually writes toolkits and GUI apps can't stand the traditional X way of doing things; it's just clueless users who can't disassociate the Windows implementation specifics from a broad idea who actually bitch about client-side windows.
But this is simply not true. It removes significant funcionality
They then claim that it's impossible to do without X because VNC remotes whole desktops and VNC is generally crappy. In other words, they are claiming that the only remoting technologies in existence are X and VNC. That is utter bullshit, of course. Even most people who do remoting on X are doing it without using the X protocol anymore, because the X protocol is actually a really horrifically bad protocol for remoting modern applications.
The really great thing about Wayland is that it actually makes modern, efficient, and flexible remoting _easier_ than X traditionally does! The entire compositor design of Wayland makes it trivial to slap in remoting in a highly efficient manner.
The only feature that might actually be lost is remote-GL, but nobody serious uses that anymore, because GLX is utterly and completely out of date with the current OpenGL specification. You can't remote any modern GL application without using proprietary GLX extensions; and if you're already willing to use proprietary remoting protocols, why cling to X in the first place?
But if you are smart, you won't bet your money on X disappearing for a long time...
Right now, X does a ton of crap directly with hardware or hardware drivers (even in the new KMS world), tying it down to specific OSes and specific technologies. You want to get a new graphics feature, you need to update your kernel and X, despite the fact that X is just a protocol, windowing layer, and event I/O dispatcher! That's silly. Worse, the entire X protocol and design makes many new desktop features impossible to implement intelligently, like a shared desktop system. (It's pulled off now with a series of hacks that has a ton of issues that degrade performance and security.) It's very non-ideal.
Instead, X can sit over Wayland. Wayland becomes the low-level abstraction to the hardware interfaces. It is even lower-level than X, allowing for much more efficient multiplexing.
So the way things will work in the future is NOT App->Gtk->Wayland but rather App->Gtk->X11->Wayland.
At some much more distant point in the future, the X11 stack may start to fade away. This will only happen when all the popular apps implement more pluggable toolkits (which means LibreOffice/OpenOffice in particular needs a shitload of work) and someone shows the world that remoting on Wayland is every last bit as easy as it is on X but even more efficient (this is more than possible, it just hasn't been written yet, as Wayland is still in early development, obviously).
What is more likely to happen is that a handful of apps will transition to natively using Wayland to bypass X. For instance, full-screen games would not need a single feature that X offers, and can run way more efficiently without the bottlenecked X design by talking to Wayland directly. Your standard desktop apps are less likely to be made native Wayland clients because there's significantly less to gain there, but the incompatibility with current common X desktops would be annoying for some users. X sticks around those apps for the foreseeable future.
You could argue that X can keep evolving, sure. Anything Wayland does could, in theory, be added directly to X. At some point, though, that stops being feasible in the current Xorg implementation. To get Xorg up to speed with what Wayland is capable of basically requires rewriting huge portions of the internals of Xorg... which is basically saying, "we don't want Wayland because it's written from scratch which is dumb, so instead we're going to write something else from scratch but claim that isn't dumb because we said so." Oh, except that Xorg rewritten would have to have all that old crufty protocol code rearchitected to support the X protocols that almost nobody uses anymore as well, because that's how the protocol works and it has to be there.
Instead, the intelligent thing to do is to Wayland running, get the hardware abstractions moved there, and then gut all the hardware crap out of X and let it sit as a protocol veneer over Wayland. You get to keep all user-visible features of X and all of its ABI compatibility, but you also get a better and more modern graphics stack that can actually continue improving without being stuck with the design decisions of X.
Finally, the X-on-Wayland idea rubs people wrong who bitch that X on Windows or X on OS X is such an awful experience. They for some illogical reason think that it's because X is not talking directly to the hardware on Windows that X on Windows sucks. That's incredibly idiotic. X on Windows sucks because Windows apps look and feel one way and X apps look and feel a different way. And that's because X apps are written with X toolkits and Windows apps are written with an entirely different set of toolkits. On the other hand, a Wayland GTK+ app is going to look and feel identical to an X11 GTK+ app. The underlying protocol used to talk to the hardware/window/IO abstraction layer is totally irrelevant.
There may well be technical problems with the design of Wayland, but nobody has actually pointed any out yet. At best, all that any of the nay-sayers have managed to do is scream "I don't understand what I'm talking about!" at the top of their lungs (in slightly different words).
Wayland is obviously not going to replace X entirely, or even mostly, anytime in the near future on consumer desktops. It's going to take years at best before X becomes irrelevant, yes. Nobody involved with Wayland has ever said otherwise.
Comment