Wayland 1.0 Released, Not Yet Ready To Replace X11 455
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."
Re:what about xorg? (Score:5, Informative)
x.org is not a replacement for X11. x.org is X11.
It's an implementation of an X11 server.
x.org split off from XFree86 over licensing arguments, if I recall properly.
Re:what about xorg? (Score:5, Informative)
The licensing thing was basically just the last straw in a long line of disagreements, especially the lack of innovation and communicating and coordinating with the rest of the community, like projects such as KDE and Gnome.
If you think x.org's development is glacial, it's nothing like what XFree86's BS was.
--
BMO
Re:Might be faster than you think (Score:2, Informative)
Wayland is not compatible with X11. You can recompile a GTK program so it runs on Wayland, but existing X11 apps do not run on Wayland (they are working a crappy-ass Mac OS X like shim).
Re:Application and Screen on Different Machines (Score:5, Informative)
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
Re:what about xorg? (Score:5, Informative)
The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times. Nobody renders like that. The only way to reuse such an API to render modern UIs (without using GPU functionality) is to generate bitmaps using various modern rendering libraries and toolkits (like Qt does!) and push those to the screen. Thus, for a modern application, X11 and GDI are bitblt and input with lots of other junk nobody cares about. Yeah, X servers were working fine on resource constrained Unix systems 20 years ago, but then the UIs back then consisted of relatively simple primitives that the X server could actually draw. 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.
The legacy APIs are useless, they don't scale anymore. Back in times of X, any application that drew anything complex had to maintain its own scene graph of some sort and maintain its own space partitioning to choose what to redraw. This led to obscene duplication of effort, and various applications had their own glitches, shortcomings and inefficiencies because everyone was reimplementing what wasn't all that easy to implement correctly in the first place.
Given the graphics hardware available today, those legacy APIs of GDI and X vintage expose a model that is so far detached from how the hardware processes the geometry, that applications that merely use the API can't leverage the available graphics horsepower. 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.
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.
Re:Why are graphics awesome on Android? (Score:3, Informative)
Re:How long? (Score:3, Informative)
Re:what about xorg? (Score:4, Informative)
No, Wayland is throwing out ALL X11 compatibility, and removing network transparency, and all the programs that are designed to support it.
Fluxbox?
Re:Application and Screen on Different Machines (Score:5, Informative)
Note that the X.org developers are not the original X11 developers, they are just the developers of a replacement implementation that copied the old *nix code using modern techniques. They did a good job and I appreciate their work, but they aren't the reason X11 was in use when they started X.org and it really says nothing about their understanding of why the X11 features are there, or what the needs of other developers are. They know about their own code, and they features they use in their own clients.
You mention the bandwidth of your connection, but it is actually the latency that you should be measuring when you're doing remote GUI stuff. Even running GIMP remotely in like... 2000, on a 53.3 modem, it was the latency that would make it suck rather than the bandwidth.
Re:Application and Screen on Different Machines (Score:4, Informative)
X11 doesn't "push push bitmaps around" unless you direct it to do so.
And it pretty much always does so nowadays given that's how most modern window managers and toolkits interact with X (all rendering is done offscreen and X is simply asked to draw the resulting pixmap)
Re:Application and Screen on Different Machines (Score:4, Informative)
Wayland does exactly that and should be very good at network transparency.
Yes it sends images of the windows. This is a win because it is much much simpler than any scene description and it will not be obsolete 1 year from now. It does seem like it is more data, but for modern GUI that is in fact the most efficient way to represent the picture being drawn. You are aware that many modern apis draw MORE than one polygon per pixel?
Advantages over how X11 does images is that it avoids round trips and does not require perfect end result images, allowing compression. It also has the necessary calls to do incremental update (ie the client can say what part of the window has changed since last time, something missing from X11 images).
Re:what about xorg? (Score:5, Informative)
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.
Re:Hopefully another 25 years or more (Score:2, Informative)
Warning, sliders spotted! In WHICH universe is xterm fast? Try "time cat " on xterm and something sane like Konsole and you'll see for yourself that xterm is multiple times slower.
Re:How long? (Score:4, Informative)
Network transparency is very useful for administering servers
You're in luck then because Wayland will provide exactly the sort of efficient remote display necessary for this and most other use cases. Here [youtube.com] is the man himself, Kristian Høgsberg, demonstrating a prototype of this. Watch and learn and try to make allowance for the fact that this stuff has probably never run beyond any anything other than Kristian's development machine.
Wayland supporters have suggested using VNC for that
The blind leading the blind. Wayland, by its nature, has precise information about what it composites. Kristian explains how this can will be used to make efficient, round-trip-free remote displays work.
Eventually Wayland will provide a better remote desktop experience than X. Please know of what you speak before you condemn it.
Missunderstanding the issues (Score:5, Informative)
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...