wiredvanity

On the X Windowing System and why Google isn't using it for Chrome OS
14 July 2009

The following is an eMail response by my friend Eike Hein to a blog post by John Gruber. He kindly allowed me to post this here after I insisted, that it would be a waste just to keep this as an eMail.

In “Putting What Little We Actually Know About Chrome OS Into Context”:

> the ancient X Window System

This doesn’t sit well with me. It’s a mischaracterization.

First of, the moniker “X Window System” refers to a set of specifications defining the basic rules of a windowing system, some guaranteed functionality and rules for extending the system. Not, however, to any particular body of code.

This is important to note because while in practice there is one dominant implementation of X today, it means that continued development of the system isn’t about haphazardly piling code onto existing code, but rather has a specification side to it that is dissolved from the details of any particular implementation and that requires careful thought and planning.

Now, a major design trait of X – again referring to the system and its specification, not any particular body of code implementing it – is that it is highly modular and extensible, and this is key to its longevity. Functionality, even whole paradigms, are bottled up in extensions to the system. As new ideas and needs arise, new extensions get specified and implemented. Older extensions that have newer, superior replacements or implement outdated ideas and technology eventually fall out of fashion and are removed from implementations when the number of their users (more on who those are in a minute) can no longer justify the maintenance burden of carrying them along.

As an example, over the last three to four years, the X-based open source Linux desktop has transitioned from a traditional display model in which window contents used to be drawn directly to the framebuffer to a composited display model where window contents are drawn to off-screen buffers and combined to a full desktop image by a separate process. In a desktop environment such as KDE, the application performing this compositing process will usually be managing the desktop as an OpenGL scene graph. In other words, the X-based Linux desktop today works as “Quartz Extreme” on OS X does, and this was facilitated by adding a number of new extensions to the X Window System and required essentially no changes to existing applications.

There are many other examples of significant paradigm shifts in X over the course of its lifetime that were realized by way of adding new extensions – large-scale changes to its 2D rendering model, a full replacement of the way text is done and fonts are managed, changes to how authentication is done, etc.

Thus the X of today isn’t fairly characterized as “ancient”, but is in fact in many ways fairly young – because the set of extensions/specifications in active use today, and their implementations as well, are markedly different from what was in use at the time of its inception, or even 10 years ago.

Meanwhile, application developers are largely protected from caring about these under the hood changes, because they don’t deal with the API of X itself, but with the API of so-called toolkits, libraries that implement the building blocks of application UIs on top of what X offers to bring them on screen. These toolkits, then, are the aforementioned users of the various extensions.

On the whole, X is a technology that has proven flexible enough to adapt to and morph into what is needed again and again – few technologies can claim such an impressive track record in this respect – which is why we continue to use it. Rather than replace X to meet new needs, we work within it. It’s a framework rather than one specific way of doing things.

Now, why then does Google not use it in Chrome OS? The technical explanation for this is “they simply don’t need it for what they’re doing.”

This will need some more backstory, which interestingly involves KDE and Apple in addition to Google.

The KDE desktop environment and its libraries are based on a toolkit called Qt. In terms of what it does, Qt maps roughly to Cocoa, Quartz 2D, CoreAudio, CoreVideo and CoreData on Mac OS X.

KHTML and KJS, the HTML and JavaScript engines written by the KDE project, also use Qt to get the job done. When Apple selected KHTML and KJS to solve their browser problem, they wrote an adapter layer called KWQ that essentially implements the subset of Qt used by KHTML and KJS and makes them work on OS X – i.e. KHTML/KJS calls into KWQ, which calls into Mac OS X libraries.

Over time, as others became interested in WebKit, this adapter layer situation evolved into a proper abstraction mechanism where the core of the engine works on top of a backend that can be switched out. In addition to the OS X backend, there’s now also a Qt backend again (a copy of WebKit is today included with Qt), a cairo/GTK+ backend (the library stack used by Gnome) and a number of others for various different platforms.

Now on to Google. In 2005, Google picked up a number of former employes of a mobile device manufacturer called Danger Incorporated, including its CEO and co-founder Andy Rubin. Danger Inc. was the company behind a Qwerty-keyboard-equipped device called the HipTop that managed to garner a small cult following and was also the first mobile device to ship with an integrated application catalogue allowing for purchases of third-party applications by users, as far as I know. This group of new hands formed the basis of the Android project within Google.

Another acquisition Google made in 2005 was a company called Skia Inc. that marketed a 2D graphics library also called Skia. The Skia library, written in C, does vector graphics, text, and images. It was open-sourced in 2008.

In writing Android, Google used Skia as the graphics backend for its windowing system and GUI toolkit. They also wrote a Skia backend for WebKit, which is used in the Android web browser. This same Skia Webkit backend is also used by Chrome on all of the platforms it supports.

Now, the Linux kernel offers a framework that gives userspace access to the framebuffer of video adapters, with the drivers for those inside the kernel. This framework is not used by the dominant implementation of the X Windowing System – it has its own video card drivers that communicate with the hardware -, but for example for high-resolution text consoles, fancy animated boot screens preceding the startup of X, and in mobile and embedded scenarios.

What Google has done in Android, and will do in Chrome OS, is write a simplistic windowing system using Skia, and let that output directly to the device framebuffer, via the aforementioned Linux framebuffer framework, or other but basically similar hardware-specific means (kernel modules cooked up by the chipset manufacturer, stuff like that). Also, while I’m no expert on Skia, I assume it also has a backend implementing its painting operations via OpenGL, which would then make it easily hardware-acceleratable on a variety of different hardware offerings.

This isn’t uncommon at all. Skia is similar to the graphics engine in Qt, called Arthur. Qt being a cross-platform toolkit – it works on Linux, OS X, Windows, Windows Mobile, Symbian/S60 and some other platforms – Arthur has a number of different backends, such as a software rasterizer, XRender (for the X Windowing System), GDI (Windows), Cocoa/Quartz 2D (OS X) and OpenGL. And there also used to be a Qt-based mobile/embedded platform called Qtopia that had Qt running directly on top of the Linux kernel by way of the framebuffer framework and the software rasterizer (or a hardware-specific painting backend) and a simple windowing system written using Qt called QWS.

So to sum it up: Google already has Skia-on-kernel-without-X working in Android, and they already have Chrome/WebKit using Skia. Chrome OS is unlikely to have the sort of drag-windows-around-on-a-desktop user experience that OS X or KDE offer (I expect it will be something more iPhone/Android-like), so while they could certainly use X, the small subset of its functionality they actually require is easily written anew using Skia, and doing so means they don’t have to import a significant outside codebase and get involved with its development.

I do also think there’s a non-tech reason, however, and the essence of that is found in your recent “Mobile Phone Keyboards“ piece. Like Apple when it comes to the iPhone, I believe Google wants Chrome OS to embody a particular user experience and approach to application development. Opening Chrome OS to the massive amounts of existing X apps and their UI paradigms and such would conflict with the purity of what they want to do.

(Yes, I need a blog.)