GUADEC: Work in the pipeline for GNOME

GUADEC incorporated a blend of old and new business; there were status reports and updates from various GNOME projects and teams, but there were also a lot of sessions devoted to discussing new components and ideas for the coming development cycle, and for GNOME's long-term future. Some were wild concepts, of course, but not every new scheme was a radical departure — many were just solid bits of engineering that will make life easier for developers (and for users) over the next few releases.

Smooth G

For example, one of the week's largest crowds gathered for Owen Taylor's talk about enabling jitter-free animations in GTK+ applications. Smooth animations are not a new idea, but it has taken a while for the right approach to fall into place. Taylor addressed one specific type of animation: 2D redraws, of the kind that are commonly found when dragging or re-sizing an application window, or when translating an object across the screen. GTK+ and GNOME applications have never performed all that well in these circumstances, with tearing and jumpy updates being among the common complaints.

Taylor identified the root cause of such unpleasant visual artifacts as a lack of synchronization between the application and the compositor (following a lengthy investigation, documented on his blog). Historically, compositors attempted to draw new frames whenever they happened to arrive from the application. But this resulted in uneven timing. At times an application might generate more frames than the frame rate (say, 60 frames per second), causing some frames to be dropped, at other times it produces frames too slowly (either by consuming too much CPU or due to system load), and at still other times it may deliver frames too late to be drawn (with a buffer swap during the display's vertical blanking interval). The result is redraws that are unevenly spaced, so they appear jumpy to the eye. The compositor can attempt to be smart about which frames to draw and which to drop, but there has never been a mechanism for applications and compositors to keep in step with one another.

Taylor's solution is to introduce a frame synchronization protocol, which allows the application and the compositor to agree on redraws. The protocol centers on _NET_WM_SYNC_REQUEST_COUNTER, a counter (managed by the X Synchronization Extension, and visible to both the application and the compositor) which the application increments to an odd value whenever it begins to update a new frame of the animation. When the application finishes drawing the new frame, it increments the counter to even, and the compositor can draw the update to the screen. When the update is complete, the compositor sends a _NET_WM_FRAME_DRAWN message back to the application. This synchronization scheme does not enable faster frame rates, but it ensures that the compositor is drawing updates as fast as the application can produce them, be that 30 frames per second, 40, or any other number — and that the application will not draw new frames before the compositor is ready for them

Taylor also observed that there are side benefits to this scheme, including that frames are dropped only when the compositor fails, and that it is possible to benchmark compositor performance independently. That should enable future work benchmarking and improving compositor performance. Taylor implemented the frame synchronization protocol in the Mutter window manager used by GNOME, but he also posted it to the window manager specification list, where it drew positive reactions from KWin developers and others. He had demonstration animations on hand illustrating the smoother performance on several animation effects when frame synchronization was active. The demos included window dragging and rescaling, but there is still some work to be done to make more and easier-to-use animated effects in GTK+ itself.

To the trees

Colin Walters's OSTree does not extend new features to the GNOME environment or applications, but it is designed to make life simpler for both developers and users. The concept is to replace the package-centric installation model with a Git-like repository of the entire filesystem tree — which can be cloned and updated on the client machine. Installing a new operating system is a matter of cloning the repository, and updating it is a matter of pulling in the changes. But unlike a simple OS ghosting setup, OSTree can retain multiple, named versions of the tree and boot into any of them. That allows developers to do things like maintain experimental builds, roll back to earlier versions to try to reproduce bugs, and ensure that the entire development team can boot an identical set of components.

In his talk, Walters described another feature that OSTree would provide to the core GNOME team: the ability to bisect regressions down to a single commit. As he described it, a regression means an unintentional break in functionality. GNOME has historically had problems identifying and fixing regressions because the vast majority of GNOME users do not install the environment directly: they install packages delivered by their distribution. That separates the discovery of the regression from the commit that caused it by a considerable gulf — both of time and activity. First is the commit, he said, followed by time, then the creation of a tarball, followed by more time, then the package, still more time, the release of the package to the repository, yet more time, installation of the package, updating the filesystem, then finally a reboot, after which the user notices the regression.

If developers and users could immediately see the changes, Walters said, they would find and fix regressions much faster. Walters's ostbuild is an auxiliary build tool that makes this possible. It watches a git repository and creates binary builds stored in an OSTree repository based on each commit. Because ostbuild only re-builds changed components (and OSTree only stores changed portions of the system), it does not use an excessive amount of space, but more importantly it allows developers to track down exactly which commit caused a regression.

The resulting improved feedback rate is one benefit, he said, but OSTree also makes reverting regressions simple: a new commit that fixes the regression can be deployed from the repository, and users can simply boot into a pre-regression OS until a fix is available. Such an option is impossible with traditional packages like those used in RPM and Debian systems, he said, because they rely heavily on the version numbers assigned to packages — and the definition that version numbers must strictly increase over time. OSTree and ostbuild are also fully atomic (side-stepping several problems common in package managers), they eliminate the overhead and headaches of working with GNOME's existing build system jhbuild, and they make it possible to incorporate continuous integration testing into GNOME development.

On the other hand, Walters cautioned that there are a number of issues with using OSTree that have yet to be worked out. For starters, there is no way to push out security updates (as distinct from any other commit), which could prove annoying for system administrators. It would also be necessary to find a way to integrate the OSTree distribution model with existing governance structures that define policy and longer-term strategic decision-making — and in a related issue, without the version numbers required by packages, it would be hard to do marketing and branding to highlight a new release. At a more technical level, there is not yet a preferred way to install applications from outside sources (although OSTree itself is agnostic to how applications are installed), configuration files in /etc make automatically rolling back to a previous version risky, and as Walters put it, the whole system is "barely documented."

Despite such shortcomings, Walters has been using OSTree for GNOME development for several months, via a service running at ostree.gnome.org.

Other bits

Plenty of other sessions dealt with GNOME's immediate and near-term future. Emmanuele Bassi addressed the plans for GTK+ and Clutter, the two most prominent GUI toolkits used in GNOME. One of the most frequently asked questions is whether the two should be merged into a single toolkit, given that in many ways their features are complimentary. Bassi's answer is that they need to remain separate, but both need to be adapted so that they will work better together. Clutter 2.0 is still in development, only after that will the plan for GTK+ 4.0 (including changes targeting better Clutter integration) take concrete form.

Alejandro Piñeiro Iglesias outlined GNOME's accessibility plans, including focus-tracking in the magnifier tool. Tim Muller discussed GStreamer's future, including more GPU support and improved memory management. By and large, major changes like Walters's OSTree were a rarity; most of the work that goes into each successive GNOME release consists of incremental improvements, even if (as in the case of Taylor's animation work) the result fixes a long-standing issue.

[The author would like to thank the GNOME Foundation for travel assistance to A Coruña for GUADEC.]