Please read my blog's comment policy here.
Every now and again, someone reports that Internet Explorer is "slow" when rendering an animated GIF file. Typically, they'll load a lengthy animation in Firefox and IE and note that it runs much more quickly in Firefox. Similarly, Chrome and Safari are "slow" while Opera is "fast." Conversely, there are bug reports against Mozilla complaining that they're rendering "too fast" and should render the image more slowly.
What's going on here? Legacy compatibility with ancient versions of Netscape. An animated GIF specifies its own frame duration internally, but some of the original tools specified extremely low frame-durations (e.g. 0ms) knowing that Netscape would render the image no faster than about 10 frames per second. Therefore, if IE encounters a GIF file with a frame duration of 50ms or fewer (20fps), it will delay the animation to 100ms (10fps).
A sample image (a 2.7MB GIF mislabeled as a JPG) was reported by someone in the community and can be found here.
Update: IE10 Consumer Preview increases the supported frame-rate; frames may be shown with a delay as little as 20ms. If the server specifies a lower delay, the animation is delayed to 100ms for legacy compatibility.
So an animated gif with frame durations of 51ms with be fine, but once its hits below that, frames are dragged way down to every 100ms?
Why not just maintain the floor at 50ms?
Luckily no one has used an animated GIF since the fall of GeoCities and this has become a non-issue?
@Paul: The exact rationale is lost to the sands of time, but I'd imagine the explanation is that it was found (over a decade ago) that the "bad" tools would generate values below 50ms (expecting to get 10fps), and the "good" ones would generate values above 50ms. Hence, as an accommodation for "bad" tools, any value less than 50ms was demoted to the "compatible" 100ms value.
@Stephen: It's fair to say that animated GIFs are far less common than they once were, although they're still commonly used for progress spinners and the like.
@Paul Irish: FWIW, the GIF spec specifies times in 1/100ths of a second, so 51ms is not possible to use as a GIF frame timing, 60ms is the closest available that's greater than 50.
You posted: "if IE encounters a GIF file with a frame duration of 50 or fewer milliseconds (20fps), it will delay the animation to 100ms (10fps). " Does this apply to all versions of IE ?
I wish to know if the information is sufficiently reliable to keep in English Wikipedia.
Caleb: This is true for IE5 and later at the very least, but the code probably went in for IE1 or IE2.
We should just put an end to this madness and converge GIF rendering behavior. :)
Not sure if this behavior is still applyable for IE9 PP3, though.
@FremyCompany: IE's behavior here remains unchanged in the latest Platform Preview Build.
What about the case when it runs normally but slows down when zoomed and shows weird artifacts? With this GIF (upload.wikimedia.org/.../Prince_of_Persia_%281989_video_game%29_IBM_PC_Version_gameplay.gif), you see weird artifacts (ghosts of previous frames) and the performance is blocky when zoomed.
@AniGIF: I don't see any performance issue when zoomed, and this may depend on your graphics hardware. As for the artifacts, yes, this is a known low-pri issue which we're tracking with a bug #.
also shows the "ghost(s)" while negatively zoomed. (60%, 40%, etc.)
Another longstanding GIF bug: GIFs configured with a loop count of 1 always play twice in IE: bugzilla.mozilla.org/show_bug.cgi
See nullsleep.tumblr.com/.../animated-gif-minimum-frame-delay-browser-compatibility for a survey of animated GIF timings across browsers.
Here's a complaint that IE11 incorrectly delays the first frame of the animation: connect.microsoft.com/.../981223