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!