Intel, Red Hat Working On Enabling Wayland Support In GNOME 168
sfcrazy writes "After shooting down Canonical's Mir, Intel and Red Hat teams have increased collaboration on the development of Wayland. Developers at Intel and Red Hat are working together to 'merge and stabilize the patches to enable Wayland support in GNOME,' as Christian Schaller writes on his blog. The teams are also looking into improving the stack further. Weston won't be used anymore, so GNOME Shell will become the Wayland compositor. It must be noted that Canonical earlier committed to supporting and embracing Wayland. Despite that promise, the company silently stopped contribution, and it was later learned that they were secretly working on their own display server, Mir. Intel's management recently rejected patches for Mir, leaving its maintainance to Canonical. Before Intel's rejection, GNOME and KDE also refused to adopt Mir. Intel's message is clear to Canonical: if you promise to contribute, then do so."
More petty bickering (Score:5, Insightful)
It's exactly what the Linux desktop needed! Thanks, everyone!
Re:Redhat? (Score:5, Insightful)
Care to supply actual evidence of these claims? Because anyone can make wild claims, what gets attention is evidence, which your post is lacking.
Re:Is Canonical TRYING to piss everyone off? (Score:4, Insightful)
Re:Why? (Score:5, Insightful)
Re:More petty bickering (Score:4, Insightful)
How is this any different from the rest of Linux? Oh, KDE is blah, let's create GNOME! or "I hate distribution YYY, lets make ZZZ!"
How is Wayland vs. Mir any different? "Oh Wayland isn't coming along, let's create Mir!". I thought variety within Linux was a good thing which is why we have a million Linux distributions and forks and other stuff.
How is this any different from the other flamewars that happen? KDE vs. GNOME, vi vs. Emacs, Linux distro vs. Linux distro.
Re:Why? (Score:3, Insightful)
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
If you want your programs' icons to be rendered with new-in-1988 stippled lines rather than Cairo and your text rendered with blew-my-mind-in-1992 bitmapped fonts rather than OpenType, then yes toolkits could use the original X11 drawing conventions. However not many people actually want that.In any case, if you are happy with every toolkit implementing everything twice, why not be happy with one of those implementations being Wayland and the other being traditional-style X11?
There's also the problem that X11 is far too 'chatty' a protocol. While network bandwidth available to a typical user has increased exponentially in the last twenty years, the latency has not reduced by nearly as much. This leaves a serious problem with all the excess round-trips that can't be fixed without making completely incompatible changes to the protocol.
Re:Why? (Score:5, Insightful)
My remote X11 clients run on these machines and present their UIs on my local X11 display server running on my laptop. While it is probably true that these clients are not transmitting XDrawLine and XFillArc protocol elements to render their UIs, they are still mostly assembling pre-rendered bitmaps, widgets, and font glyph assets to send down the wire for rendering on the local server. How is this going to work on Wayland?
Actually, what the clients are doing right now is assembling bitmaps, widgets, and font glyph assets into a pixmap on the client side, most likely without the benefits of GPU acceleration, and sending the result as an uncompressed pixmap over the wire to the X server, which hands it off to a compositor, which combines the pixmap with images from other applications and hands the result back to the X server. If they're luck enough not to need any special transformations or compositing effects, the clients may be able to leave the rendering of the individual font glyphs to the server, but that's about it.
With Wayland the clients are doing the same work to assemble the surfaces for their windows, but they get to use the local GPU to do it, and the result is compressed by a local off-screen Wayland proxy server using modern video codecs before being transmitted over the network for compositing.
On a desktop, the only advantage to Wayland is that it facilitates implementing a pretty compositing desktop. This is a fad that is already starting to fade from fashion.
Distracting toys like "wobbly windows" may be fading from fashion, but composited desktops are here to stay.