Slashdot Mirror
Wayland 1.0 Released, Not Yet Ready To Replace X11
An anonymous reader writes "After being talked about for four years, Wayland 1.0 was released today. The Wayland 1.0 release doesn't mark it yet as being ready for Linux desktop usage but just being API/protocol stable for future expansion. Wayland will now maintain backwards compatibility going forward, but how much longer will it take to replace X11 on the Linux desktop? Quite a while seems likely."
Hi Bill,
You have a good point, but unfortunately the X system is fundamentally flawed at the technical level for the purpose you describe. When X was originally developed, graphics were simple aliased lines and bitmapped fonts. In the modern computer environment, this has presented itself as a grave hindrance to the usability of X.
Modern applications depend on graphics toolkits, such as GTK and Qt, which render in to X pixbufs and finally those are rendered on the display. The process by which this happens depends upon copying these toolkit-rendered images from buffer to buffer several times, quite needlessly to fit within the X framework. This is moreso true over a network connection. The very nature of modern programs has progressed way beyond what X was intended and optimized for. It is like trying to use a MUD infrastructure designed for textual interaction as the basis of a modern GUI framework, it simply isn't the right tool for the job.
An anecdote, this weekend I decided I was going to work from home. So I ssh into my work computer (6 miles, 20+ Mbps connection), and fire up an X forwarded my graphical editor session. Things were slow, but not unusable until I did something that caused a series of tooltips to be rendered. The session locked up for 2 minutes before I killed it. I then fired up a terminal-based text editor and got to work. X's network transparency was not beneficial. But there are many network protocols that have been designed for the purpose of remotely operating modern GUI applications such as VNC and RDP. These have been designed from the ground up to provide the functionality we expect on today's systems.
And before I finish my tirade, I, too, was a die-hard X fan until I decided to see what the Xorg folks had to say. Keith Packard (a lead developer on Xorg, inventor of Cairo and much more that you depend on when you fire up your workstation), has been a hard proponent of Wayland. He's given many talks outlining the design failings of X and how Wayland resolves them. I recommend you google "Keith Packard Wayland" and see what you find.
Regards,
oursland
The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times.
So?
I hear this a lot. The thing is, the code might have been large and complex 25 years ago when X11 was new. The code hasn't grown. By modern standards it's small and simple. And if it's rarely used, then it will sit on disk un-paged and never getting in the way. Actually with the removal of many things which used to be but no longer are optimizations it's shrunk.
Rarely used code does not affect performance.
Nobody renders like that.
I'm going to keep using xterm thanks. And I'd appreciate if you didn't make false claims about me.
These days the X server doesn't support the primitives the application designers need, because to do so would mean reimplementing, for example, a path based compositing renderer.
Firstly, X11 does support basic compositing now, and has for a while. Secondly, what's with the claim about "reimplementing"? One could easily make a cairo-x11 extension. In fact there used to be a x11-DPS extension so it's clearly possible.
The legacy APIs are useless, they don't scale anymore.
[citation needed]
Anyway WHO CARES? Modern toolkits don't use the "legacy" APIs and old programs aren't big. So it's all happy and nice.
IOW, if you code to X or GDI APIs, your application will perform poorly and there's no way for something on the implementation side of the API to fix it for you.
Your claim is something like 20 years out of date. X11 has had a standardised interface to hardware accelerated OpenGL since before PCs even had 3D cards. Most people don't and didn't use it because even the "poorly performing" "legacy" APIs are entirely fine for almost all programs which sit there doing nothing until a key is pressed.
When designing an application of any sort, the graphics API needs to present primitives and abstractions that translate well into efficient uses of graphics hardware. I'm sure people who deal with accelerating modern frameworks like Qt will tell you all there's to know about how broken the legacy API is when faced with modern hardware.
Well, yes, but then again. they probably don't use "legacy" APIs, prefering to use things like XComposite, XFixes and so on and so forth.
Basically, the X11 prorocol is really well designed, upgradeable and does a lot of things very well. One part of it (the original drawing protocol) was basically due for a major upgrade. That partly happened with XComposite and off-screen rendering. It could (and probably should) be continued with a higher level (e.g. SVG) drawing protocol.
Other parts of the X11 protocol have aged very gracefully, and are still very good.
SJW n. One who posts facts.
The two main complaints I see discussed here appear to derive from some fundamental misunderstandings about what Wayland is.
Wayland is a Protocol and an optional helper library to implementing that protocol. This protocol says nothing about net work transparency, in both the sense of enabling or prohibiting it. It also says nothing about client decorations. The key points here is not to make a decision for or against any particular technology or methodology and then be stuck with that decision for the next 20 years, like we are with X.
How or if, either of these work is all down to the compositor. The reference compositor 'Weston' does not do network transparency and leaves window decoration to the client or its toolkit. However none of the big desktops, i.e end users, will be using this compositor. For example KDE will continue to use Kwin as their wayland compositor, and KDE have already clearly said that Kwin will be decorating their windows and not the clients!
As to network transparency, all windows are drawn to their own back buffers, and where these buffers will be eventually displayed is also the choice of the compositor, and it might well just decided to send them over a network connection. e.g. like what VNC does.
I think if you base your opinion on what other people say, including me, then maybe you shouldn't comment? All of this is discussed first hand on the Wayland web site and/or mailing list.
Unfortunately since I've posted a bit late, I doubt many will read this...