Kristian’s look on things

I just got back from the GNOME Boston Summit, and spent quite a few hours traveling with my laptop at hand. This brings up the question whether Compiz Fusion is suited to be run on a laptop on battery power or not.

My current laptop is a HP Compaq NC4010, with an ATI Radeon IGP video card (IGP means no discrete video memory, among other things). Due to the age of this card, it is necessary to run X in 16 bit color depth to get fluent animations, which is something I recommend everyone with slightly older cards do.

As for battery usage, there are two concerns; Whether just having Compiz running, doing nothing, enables features on the video card that draws more power, and whether what Compiz and the general Composite environment it self causes more wakeups and thus higher power consumption. For the first question I don’t have any real answer, I would assume this varies from card to card. The second is fairly easy to answer though, with the help of Powertop. It seems to me that compiz in general doesn’t really cause much extra power consumption. Ironically, the feature in Compiz Fusion that causes the most wakeups is the mouse polling in eZoom, so when I’m traveling I set the mouse poll intervall to 500, which results in far fewer wake ups, but also in an almost unusable mouse which only updates twice a second. For me, that’s not an issue because I don’t use the mouse that much while on the road.

I’m currently at day two of the GNOME Boston summit, and I spent time yesterday discussing and pushing some of my orca hacks off to Joanmarie who’re going to fix them up and get Orca talking to eZoom.

We talked about creating a new API for general accessibility functionality to complement AT-SPI, for instance with regards to what Orca is actually doing, but decided somewhat against it as it is not really necessary. The existing D-Bus interface that eZoom offers will likely be refined to cover the needs that we discover during the implementation of eZoom-control in Orca.

The support for a cross hair for the mouse cursor was also requested, and I agreed to look into implementing it inside of eZoom, even though it could be done as a separate plugin. The reason I’m considering this is twofold: First; if you are using the cross hair you are almost certainly using eZoom too. Second; Due to the mouse code in eZoom, it is difficult and hacky at best to figure out where the zoomed cursor is.

Since I already had a patch for Orca and a reasonably sane D-Bus interface in eZoom, these discussions left me with little specific to do here in Boston since we decided to go with what we have instead of creating something new, but I assume I’ll be put to work when we all catch up, as I’ve been promised several(?) RFE’s, which is a good thing.

I recently participated in a Compiz Fusion development sprint in London to make sure Compiz Fusion is a smooth experience in Ubuntu Gutsy Gibbon, to be released this month, with Compiz Fusion by default.

We fixed some very specific issues, and generally smoothed things over. The wrapper script that is now used in Gutsy is a piece of code that started as my own code but has switched a lot of hands, but is now back under the Compiz Fusion name. It was originally intended to be used by distributions as well as users choosing to install Compiz Fusion from source, as such it has always been important for me to adapt it to the needs of distributions.

I recently installed Gutsy on two laptops, and was unlucky enough with the hardware to experience the issues we have to deal with: Hardware and driver issues. The first problem I ran into was on an evo N410C with an Ati Radeon 16MB DDR card. The problem was that the wrapper script’s tests to determine if compiz will run or not succeeded, but compiz still crashed claiming lack of FBConfig. After some experimenting I determined that the card/driver is simply confused. At a colour depth of 24 (Default), glxinfo will claim the card supports 1024 wide textures, which it seems it doesn’t. At Colour Depth 16, however, it will claim to only support 512 wide textures, so the wrapper scripts doesn’t attempt to start Compiz, however it really does support 1024 wide textures.

Since these tests are very important for both old and very new hardware, it’s a bit of a problem that they fail like this. However, it’s not easy to solve either. Not in a script anyway.

On the performance note, the card did very while running 16bit color depth. The relevant specs for the machine would be a 1.2GHz Pentium 3 with 256MB of memory. I won’t claim that openoffice and firefox is quick to boot up, but it’s absolutely usable.

The other laptop I got a hold of is a HP Compaq nc4010, considerably faster (1.8GHz Pentium M/ 1GB ram), but with an ATI Radeon IGP card. This card doesn’t have any discrete video ram, and I’ve also had some issues with it in the past on other hardware. The card was not really able to run smoothly at 24 bit colour depth, and the texture size limit seemed to be 1024 which made it far to easy to get solid white decorations when a window was maximized (due to the textures being bigger than the screen resolution of 1024×768… a bit annoying since it’s going white on behalf of image data that is off screen.).

However, at 16 bit colour depth, it was, not surprisingly, very smooth.

It seems to me that the bigger problem is that this setup doesn’t actually provide working xv output, leaving me without accelerated video. For me personally this isn’t a huge issue; I’m using mplayer’s -vo x11 combined with eZoom to watch videos, but in genera this is a bit of a major issue.

Cards like this is getting blacklisted in the compiz-manager script, though such a list is easy to override. The idea being that it’s better for people to end up with metacity working perfectly than Compiz working without proper video support.

I am very excited about Compiz Fusion being enabled by default, and a little nervous. I am not entirely convinced we’re ready for it, due to issues like what I described above. But this certainly pushes the work forward, and I believe that the people who’s hardware is able to run Compiz Fusion will enjoy it under Gutsy. The people working on the Ubuntu packages have done a good job smoothing over issues with somewhat overly optimistic configuration defaults and bugs without appropriate upstream fixes.