The article “Animated GIFs the Hard Way” has got some attention again.  I recall enjoying the article back when it was first published.

I had just one concern, though… why not just use GIF?

The perceived problem is that GIFs are a) large and b) are limited to 256 colours.

Well, first lets kill the 256 colours thing: GIFs aren’t limited to 256 colours.  They are limited to 256 colours per frame, but are made from an arbitrary number of frames and each frame can have its own palette.  Converting animations with lots of colours to GIF is quite a fun subject and there are lots of fun tools to do it in various ways.

But the chap said that all the GIFs of the content were megabytes in size, but his PNG+javascript was only 100KB.

Luckily, what looks like his test vector is in the github project.  So its just to make a classic proper GIF of these PNG frames and see how big it would be…

Using Imagemagick, that’d be:

convert -delay 20 -loop 0 screen_66030*.png -layers Optimize test.gif

And the output is… drumroll please!  100KB.

And here it is:

(click for original size)

So why not just use GIF after all?

This all reminds me of when I wrote a custom animation format for the splash screens of Motorola phones, but that was quite a bit different under the hood and perhaps that’d make a nice future blog post ;)

Where I could see client-side animation making sense is for animating screen recordings that contain composition of semi-transparent layers.  The recording of the screen would work best if it recorded draw-ops rather than bitmaps.  I did something like this at UIQ/Symbian for Content Embedding and the Transition Engine.