Byzanz 0.1.0

I’ve now arrived at what I’d call feature complete. It even has an about box! So, go grab Byzanz 0.1.0 and play with it.

So what’s new in this release? Three things: The applet got a complete overhaul, you can now record your mouse pointer and the code has been moved to Gnome CVS. What’s also new is me wondering about where I want to go with this thing. Should it be included in the Gnome desktop? Should it be made to record to other formats? If so, which? Do people want to record audio with it? Do people want to add things to these recordings (like bubbles explaining things) and need an editor for this? Do people even care? I guess I’ll need to wait for recordings popping up on the net to see what people use it for.

Another thing I’ve played around with a lot while writing this thing is GIF encoding and decoding. Encoding is interesting for two reasons. The first is performance. You want to ideally have your GIF completely encoded when you press the stop button and not have to wait until it’s done encoding. While for an average desktop session, this is no problem even on my old iBook, recording playback of a full screen H264 movie (which itself can take more than half of the performance of a 3GHz CPU) will have you wait a while for the result. So what’s so slow in the encoder?

• Color lookup is slow. Color lookup is the process of selecting that one of the 256 colors in a GIF that most closely matches the color we want to encode. I’ve yet to find an algorithm that implements that fast and efficient. The current tree-based algorithm and the “create a 64MB lookup table” approach seem both suboptimal to me – the first is slow, the second uses far too much memory.
• Dithering is slow. There’s a lot of calculations required per pixel to keep track of all the different error values. This could possibly be sped up quite significiantly by using vectorizations (Altivec, MMX, SSE), but I’m not a specialist on those.

The second thing that is interesting about encoding is the size of the encoded image. The current code already optimizes quite a bit. It tries to find regions that haven’t changed and omits them or if that’s not possible it sets them as transparent. That way you get a lot of transparent pixels, which result in a pixel array that can be compressed a lot better. You can see this by opening one of your recorded GIFs in the GIMP (which is an excellent debugging tool for animated GIFs btw). But there are of course still optimizations that might be useful, like marking a pixel transparent even though it changed, when it didn’t change a lot.

Another interesting thing are GIF decoders. Since your average GIF image is small (you know those little animations on the web – the biggest ones are probably banner ads), but Byzanz easily records full screen animations that last multiple minutes and easily exceed 50MB in size, you find the limitations of the current GIF decoding libraries easily. And you find out that every project has its own GIF decoder. And you find out when you record a 17MB animation of a short movie with around 1500 frames (the movie itself is 9MB in size, so don’t use GIFs to record movies ;)), that

• the GIMP decodes the whole image into layers and then gets performance issues when rendering the resulting file, since it has to compose 1500 layers. Changing the visibility of one layer result in a huge lag. It’s ok in memory usage though (around 300MB, probably only keeping the change regions).
• Mozilla also decodes the whole image at once resulting in rendering hickups during playback of the loading animation. When it plays back the looping animation a second time, everything works fine though. It uses as much memory as the GIMP for this (300MB).
• Internet Explorer 4 (the only one I have) opens the image fine and displays it without problems. No clue about memory usage though.
• Gtk consumes all available memory and my machine hangs. (Crappy OOM handling therefor a desktop, Linux.) This is because it tries to keep the completely rendered frames in memory. That easily exceeds multiple Gigabytes.
• note to self: test Konqueror

None of those applications handle GIF the way it was envisioned in the GIF spec: As a data stream. They all implement it like it’s used most of the time: As ad banners. I wonder if Gtk and Mozilla devs would like to get their gif image handling code improved, even if that’d require writing a new library. I’d bet on “don’t care really, the current code is good enough”.

Oh and one thing: I need icons for Byzanz that don’t suck. Feel free to create some and send them my way – or just check them in if you have a Gnome CVS account.