Interview: Kristian HÃ¸gsberg

Learn from AIGLX creator Kristian HÃ¸gsberg what he thinks is important in the world of desktop 3D and... FireWire!

What will you be speaking about at FOSDEM 2007?

The talk is meant to be an overview of how the open source rendering stack fits together - what are the technologies that make something like Compiz possible and what shortcomings in the OpenGL/AIGLX/COMPOSITE area we have to work on.

And what's the intended effect of your presentation?

It's mostly informational. If the audience leaves the session with a better understanding of how the different building blocks below Compiz fit together and what's behind the various 3-5 letter initialisms, that's great. If they sit down and start writing patches, even better :)

Why did you feel that AIGLX currently is a better approach than Xgl?

AIGLX fills a gap that was left un-implemented when the DRI infrastructure was originally designed and implemented. As such, it's not a big new development, it's more a missing piece in the open source rendering stack. It's a gradual improvement to what's already there, and as such easier to ship sooner rather than later.

Having said that, AIGLX and Xgl have often been made to look like they are more or less the same thing from different companies, when they are in fact two very different technologies. They just happen to both provide the features required by the OpenGL based composited desktops, and thus it often comes down to just "Xgl or AIGLX?".

But you guys been collaborating with the Xgl people, right?

Definitely, [Xgl author] David Reveman is a good friend of mine and we've been working together on a number of projects, such as cairo, the X server GLX module, and Compiz.

How is AIGLX going to evolve?

AIGLX, is more or less just done. There are a number things that we need to get working, such as redirected direct rendering and redirected AIGLX rendering, but these are issues that affect the entire stack.

Do you think that the recent attention for OpenGL accelerated window managers will have an impact on 3D driver quality?

Definitely, it already has had an impact. We've seen a lot of performance work and bug fixes come out of this. Some drivers, for example the R300 driver, have gone from experimental or flaky to basically stable in the time that Compiz has been around. Part of this development can certainly be attributed to Compiz.

A lot of testing still comes from games, either running natively or under wine, but there is no doubt that the new 3D desktops have generated a lot of interest in OpenGL on Linux and pulled in a lot of new users.

How do closed-source drivers impact your development activities?

Not much. I don't use them. Out of principle, I'm opposed to binary drivers and I'm very happy to see a project such as [open source 3D Nvidia driver] nouveau take off as well as it has. However, on a day-to-day basis, it's more of a practical concern; I can't work on the binary drivers. I can't fix bugs there, I can't add new features, I can't profile and fix a performance bottleneck. Binary drivers don't benefit from infrastructure changes such as AIGLX or the new memory manager work. Conversely, generally useful functionality in a binary driver can't be factored out as infrastructure. It's a black box. It just sits there and I can't do anything with it.

How does the contemporary X.org+compositing engine compare to e.g. Windows Vista's or Mac OS X' graphics pipeline?

It's getting there. I don't know the details of the two other systems, but performance-wise, Compiz easily holds up to Mac OS X. I have not seen Vista in action yet, let alone had some time to play with it myself.

One big advantage Mac OS X has, though, is that they did a clean break. If you are targeting Mac OS X, you know your application will be running in a composited environment. You know that the environment will support anti-aliased round corners on your windows or translucent overlays or whatever effect a composited desktop enables. Both GNOME and KDE are still targeting a non-composited (legacy) desktop, and we need to start thinking about how we integrate these new features into the applications and toolkits.

In a way it's like in the mid-90s where you would tweak your windows manager like crazy, trying to make your desktop of Motif and Athena widgets looks just a little bit modern. With GNOME and KDE, the Unix desktop got a long overdue face lift. Today we're tweaking the compositing manager and it's GNOME and KDE that need to catch up.

Given that "wobbly windows are so 2005", what's your favourite effect?

I really like the translucency blur effect that Vista has, and now also Compiz and Beryl. As far as translucency is useful, this effect makes it even more usable, since it tones down the details of the underlying screen contents and makes the contents of the top window stand out better.

The runner-up is one of the Beryl animation effects, where the window disappears in a blue flash or something. Like the teleporter effect from Star Trek. It sounds goofy, but it is actually pretty neat, and it's fast and stylish.

But what I'd really like to see is more of the integration I was talking about before. We need to figure out how use these new features in the desktop environments in a useful and shiny way. Maybe that's what GNOME 3 should be. Using ARGB (translucent) windows for popup bubbles or OSD overlay type of windows is a first step, but some of the more interesting and useful results will come from deeper integration with the compositing manager. Applications such as Nautilus could conceivably offload rendering the root window to the compositing manager, which would reduce pixmap pressure in the X server and enable new types of effects. Instead of just moving the login window from side to side when an incorrect password is typed in, we could ask the compositing manager to wobble it. There's a lot of fun stuff waiting to happen in this area.

Are you working on new effects currently?

Right now I'm seriously side-tracked from the graphics work I've been doing previously. I'm working on a new FireWire stack for Linux, that is, kernel driver work. At Red Hat we'd like to ship and support FireWire, but the stability of the Linux FireWire stack has been hit and miss. I have a lot of FireWire experience from my old job and have always wanted to write a high quality FireWire stack for Linux. Put two and two together and I'm working on FireWire.

One thing I'll probably be looking into later on is how to improve graphical boot so we can start the X server as early as possible and, if possible, reuse the same mode throughout boot, login and the user session.

Any new features planned for Akamaru?

Hehe, no, not at the moment. But there is a lot of potential in the physics engine there and I would love to see it [being] used more. One of my goals with Akamaru was to exploit and demonstrate some of the features you could implement using a physics engine. The dock demo that most people associate with Akamaru has forked into its own little project and they've added a bunch of features and settings.

Speaking of physics engines, I'd like to highlight one of the subtle features in Compiz that I suspect most people don't notice or maybe take for granted. All the animations in Compiz are driven by some sort of spring model. When the cube spins, it doesn't just start and stop abruptly. As you switch desktop, it accelerates up to speed, and as the cube finishes it's spin, it overshoots the target by a little bit and then snaps back into place. This is true for all the animations, whether it's the application switcher or the scale and zoom plugins. Sit down and check it out, they all have this physical feel, as if you're manipulating a real object. It's what makes compiz so cool, and we need more of that!