We're hiring!
*

Ubuntu rejoins the GNOME fold

Daniel Stone avatar

Daniel Stone
April 05, 2017

Share this post:

Reading time:

Today we all read the announcement of Ubuntu's decision to refocus on cloud and IoT activities, dropping Unity 8 to move back to a GNOME-based desktop for the 18.04 LTS. This marks a return to the fold, with Ubuntu having originally shipped GNOME all those years ago, and lest we forget, having contributed to early Wayland discussions.

This is obviously a large, and undoubtedly difficult, decision that will have ramifications for years to come. Particularly in the user-facing aspects, unifying the desktops will help combine forces and be much more productive. For developers, a lot of the differentials in desktop technology (e.g. indicators, menus, scrollbars) between the two may now be at an end, making generic Linux an easier target for ISVs. And, assuming a GNOME Shell port to Mir is not underway, we are back at only supporting two window systems: X11 and Wayland.

Fedora has already been shipping the GNOME Wayland session by default since Fedora 25, with broadly positive reception. (My personal favourite review: 'the transition to Wayland has been totally transparent ... GNOME 3.22 feels considerably smoother with Wayland'.) Should Ubuntu follow Fedora's lead and ship a Wayland-based GNOME session by default, then developers across all platforms will get all the benefits of the work done to Wayland in general, as well as EGL and Vulkan enablement, across the board for free. And we'll undoubtedly see more focus on it.

Even for developers targeting X11, given that it's still shipped by older versions of Fedora and current versions of Ubuntu desktop, the XWayland compatibility server has seen a great deal of work recently. Specifically for gaming usecases, the relative and confined pointer protocols from the Fedora team allows proper gaming-style mouse input. Our own Pekka Paalanen has done much work on making window resize as smooth and flicker-free as possible. And there is much more in the pipeline.

But enough of the differences. A major reason for reassurance is just how much of the graphics infrastructure was shared. When I started working on X11 nearly 15 years ago, the idea of a fork, or an alternate window system (remember Berlin/Fresco, KGI/GGI, DirectFB?), was unthinkable. Not just because all the drivers and platform specifics were tied up in the XFree86/X.Org servers, but the toolkits too: a lot of the big breaks between GTK+ 2.x and 3.x were about removing details of X11 that were exposed as core parts of the toolkit API.

The world in 2017, however, is a very different place. KMS provides us truly device-independent display control, Vulkan and EGL provide us GPU acceleration independent of window system, xkbcommon provides shared keyboard mechanics, and logind lets us do all these things without ever being root. GBM allocates our buffers, and the universal allocator, borne out of discussions with the whole community including NVIDIA, will soon join the family.

Mir leans heavily on all these technologies, so the change is a bit less seismic than you might think. Even this month, one of the Mir developers fixed display of cross-GPU imported buffers in KMS - thus for Mir, Wayland, and X11 - and after he landed the fix in the kernel, we continued to discuss future API changes around this. From this point of view, nothing changes, because we all share the same bedrock infrastructure, borne of X.Org's incredibly long-sighted view that it had a duty to make itself replaceable.

GTK+, scene graphs, and Vulkan

Also positively, I was able to attend the GTK+ hackfest in London last month - not least as it was a short stroll from my office - with many thanks to Red Hat and Endless for hosting. I was particularly interested in discussing the GTK+ Scene Kit, which overhauls the core GTK+ rendering system.

GTK+ 3 performs rendering effectively through a chain of callbacks: at the appropriate time, it walks through all the widgets and asks them to render their content into the pre-allocated buffer. This already is a huge improvement over GTK+ 2, which lacked the 'at the appropriate time' qualification.

GTK+ 4 with GSK will take this a step further, asking each widget to instead _describe_ how it would render itself, with the actual rendering being performed in a single step at the end. This approach allows the rendering to be much smarter: shared assets can be cached and used once, similar operations can be performed together in a batch operation, and the core renderer can broadly make much more smart scheduling decisions. (Those with a sharp sense of history may remember some of these principles from Clutter 2.x.)

OpenGL users should see large improvements. One of the biggest bottlenecks with OpenGL performance is usually related to state changes. Every change such as enabling or disabling alpha blending, switching textures, et al, causes a flurry of state-change requests through the GL API, all of which have to be individually validated. With GSK making batching possible, state thrashing can be avoided as much as possible.

On the other hand, Benjamin Otte has been working on a Vulkan backend for GSK. Vulkan is also a natural fit for GSK. Vulkan encapsulates all this state into pipeline objects, which are expensive to create ahead of time, but virtually free to switch between. We had some excellent discussions around the APIs and how to make this possible, and whilst the initial implementation is far from optimal, I really look forward to seeing this mature, and seeing GTK+ be able to really make the most of modern GPU performance.

Of course, the GTK+ hackfest was not all about graphics. Simon McVittie was also there, having very different discussions to me, and has an excellent write-up of the discussions on how best to secure D-Bus for containerised applications. Matthias Clasen, who did a fantastic job organising the hackfest, also has a more general hackfest write-up.

With all the progress being made here, and Ubuntu rejoining the fold to not only help push these efforts forward but also bring their own focus and sizeable desktop userbase, the future seems about as sunny as an early spring day. Welcome back, Ubuntu!

Comments (3)

  1. nixCraft:
    Apr 07, 2017 at 11:27 AM

    This is awesome. Now desktop users of Redhat, Fedora, CentOS, and Ubuntu all have same user experience.

    Reply to this comment

    Reply to this comment

  2. Pip:
    Apr 07, 2017 at 11:49 AM

    Whoever you are, thank you for all the excellent work. As a long time Fedora user, I'm enjoying the experience more than ever before. Hopefully applications like gimp will follow the progress. At HiDPI they're for now useless. So sad.

    Reply to this comment

    Reply to this comment

  3. Oscar:
    Aug 22, 2017 at 09:56 AM

    Thanks all of you that are working for a better GUI experience in Linux and Unix.

    Reply to this comment

    Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Automatic regression handling and reporting for the Linux Kernel

14/03/2024

In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…

Almost a fully open-source boot chain for Rockchip's RK3588!

21/02/2024

Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…

What's the latest with WirePlumber?

19/02/2024

Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…

DRM-CI: A GitLab-CI pipeline for Linux kernel testing

08/02/2024

Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…

Persian Rug, Part 4 - The limitations of proxies

23/01/2024

This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…

How to share code between Vulkan and Gallium

16/01/2024

One of the key high-level challenges of building Mesa drivers these days is figuring out how to best share code between a Vulkan driver…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2024. All rights reserved. Privacy Notice. Sitemap.