KDE Plans To Support Wayland In 2012 413
An anonymous reader writes "During the 2011 Desktop Summit plans were brought up by a KDE developer to support KDE on the Wayland Display Server, which is dubbed the successor to X11. The KDE Wayland support is expected to come in three phases, with the first two phases expected to be completed next year during the KDE SC 4.8 and 4.9 development cycles. Farewell X?"
Misleading! The point is to keep X compatibility. (Score:5, Informative)
Typical slashdot: the article distorts the truth in order to get reactions.
It was pretty clear during that presentation that the goal was to make it possible to still run X applications -- using a rootless X server -- and that this would also allow X-over-the-network use cases.
X11 is not going away, the idea is to use Wayland -and- X.
Re:What's wrong with X11? (Score:5, Informative)
The main problem with X11 is the complete lack of frame boundaries. Applications just send a stream of drawing commands with no indication of where one frame stops and the next one begins. Consequently the server has to keep drawing stuff as it comes in, resulting in flicker. Flicker is the first thing a novice X11 programmer complains about and online forums have been filled with pleas for help with this problem for decades. The traditional solution was to render to an offscreen image and send it to the server. This requires a lot of bandwidth, so the next step is to use MIT-SHM extension to avoid this traffic. Then came XComposite extension which automatically handles double buffering. XComposite has the luxury of being able to sync to vretrace, but not knowing where the frame boundaries are it can't do it lest it cut the instruction stream in the wrong place and draw half-a-screen. In the meantime, after two decades of deliberation, the XSync extension still does not implement the ability to detect vretrace.
Wayland solves the above by moving rendering into the client, as in the render-to-image solution above, and then copying the image to the server. This can be done though shared memory as well. The rendered image on the client represents the complete frame.
Re:Stupid (Score:3, Informative)
So somebody that has not even heard of the root window is trying to tell us all what X can or can't do and getting it wrong?
BTW, the gnome and kde comments also show a lack of understanding - there's more to X than a widget set and ultimately the important thing is getting the images from whatever to where the user can see it.
Re:Stupid (Score:5, Informative)
So somebody that has not even heard of the root window is trying to tell us all what X can or can't do and getting it wrong?
I'm pretty sure Keith Packard, as a lead of X.org, has heard of the root window.
Here is the video I was referring to: X and the future of Linux Graphics. [blip.tv]
Re:Not so stupid. (Score:4, Informative)
Well, you can move things into the X server, but currently X doesn't support anything like the functionality that cairo needs. There is no X command for drawing a bezier path. There isn't even an X primitive for drawing an antialiased line. That's why people use things like Cairo.
Now, ideally, I'd like something a bit more like Apple's display server, where PDF-like commands are streamed directly to the display server, which can then do the 2D rendering and compositing. One of the first things I'd do if I were implementing X12 is ditch all of the existing X11 drawing commands and add most of the PDF 1.4 operators - in fact, the set that the HTML 5 canvas tag exposes to JavaScript would do very nicely.
Re:Stupid (Score:5, Informative)
Hmm, interesting; thanks for the link. I hadn't realized that the X.org people are moving in the same direction. Doing a bit of googling, this LWN article [lwn.net] summarizes a Packard talk from last year that seems to be hitting some similar points.