User blog comment:Makallus/Deco GIFs/@comment-5116140-20120814213513/@comment-5246522-20120814222631

I've seen this in a number of software packages over the years. These assets are technically called a 2d "texture" or sprite sheet and kind of go way back -- there are numerous reasons, memory, the speed of a pointer in an array, server round-trips and so on. In my implementation I only fetch all of the frames once from the sprite sheet and put them into an image stack in memory. Then as I play the frames they just get rendered to the canvas on frame refresh. The raw sheet is technically junk by this time (and could be disposed) but I left it up in the first demo to illustrate what the source files look like. In the subsequent demos I still have the raw sheet hidden (style=display:none) so I can display them for debugging. In the final version I can delete the rawCanvas and frameCanvas document element to save memory on the client.

I wanted to do it this way so that if this wiki decides to adopt the code the admins can easily add new dinos by simply loading the sprite sheet and the plist and hand them to the routine. No extra steps required.

I'm tracking down some browser compatibility issues with Mozilla too... seems the DOMParser (for xml, which is the PLIST) is different in each browser and handles (or, doesn't handle) the junk in the plist differently. IE9 is completely jacked due to its handling of the Canvas no to mention it's own xml parser which pukes on the raw plist too.