To be more clear on the gh_pages idea. If you rename your master branch to gh_pages then github will automatically let you browse to it. For example one of my projects which includes a index.html just like yours on github:
How strange. Until last month, I was running gifexplode.com, a site where you could share 'exploded' gifs - i.e. it took an animated gif and stepped over it frame-by-frame. I took the service offline last month because people were using it to store porn. I had tried finding a client-side solution in vain. The long-term plan for gifexplode was to introduce a player just like this!
Soon as I get a chance, I think I'll relaunch gifexplode with your viewer.
This was meant as a proof-of-concept and has several big inefficiencies that could be fixed pretty easily if someone was actually going to use it for something. The UI could also be improved, and I think at least IE9 could be reasonably easy to support (though I haven't tried).
I was using XHR because an important constraint was to do everything client-side, and there's no other way that I could find to get the raw image data. If you have server-side support, though, a lot of things can be made much simpler. Is there a reason not to proxy, like crux_ suggested?
Instead of mirroring, you could proxy. (Solves "storage"/"mirroring" issue; doesn't solve "nasty stuff served up through your server" issue.)
In general, though, there's no way around it, except of course by restructuring gifexplode as a bookmarklet or convincing image host(s) to partner with you:
They can then include the code on the pages they serve up themselves, allow XHR requests via HTML5 or flash mechanisms, or give you base64 data smuggled into a JSONP.
Thanks, yeah I think proxying is the best solution. I'm still not sure if that's a route I want to go down though... The nasty stuff served through my server is what I want to avoid. Gifexplode became quite popular on 4chan you see...
I like this simply for the content on the page, not necessarily the actual project (tho it's cool too). It's snarky, self-deprecating, and dryly funny.
It also uses a canvas element to render each frame but it does support weird disposal methods. You can see the (very sloppy) source by just viewing the source of the plugin window.
You mentioned getting test images for the disposal methods and I found these to be very helpful: http://algif.sourceforge.net/#18
I'd also recommend using some kind of movie player-style control like I used and some kind of "explode" function. They both proved popular.
This is the way forward for codecs on the web. Alan Kay has previously complained about how dumbed-down the browsers are in comparison to the possibilities of mobile code, and that's now starting to become less true.
The next step beyond that is to provide browser extensions for programming network protocols. One-way HTTP over NAT sucks, web-sockets do not and will not work.
We're starting to come back around to the vision of the Internet in the 80s - multi-protocol, multi-host (if you're on the web, you can be a server), mobile code via bytecode (or source code), and with pervasive remote access (VNC and X11/NX).
Nice! I was swearing at Wikipedia's animation of a flipflop a couple days ago. Downloading and fiddling with 'convert' was substantially more annoying.