Bug 14413 – GIF animation throttling is different from MSIE

• Status: RESOLVED
• Resolution: FIXED
• Component: Images

IE and Opera have a minimum delay time between GIF frames, empirically found to be 100ms.  Mozilla also has code for this, though it was broken in FF2.

Safari does not appear to have a frame rate throttle, or if it does, it appears to be set below the other browsers.

Test URL appears to be running unthrottled in Safari 3.0.2 (windows) and webkit nightly (os-x).

[Alexey Proskuryakov]

This is from WebCore code:

    // We follow Firefox's behavior and use a duration of 100 ms for any frames that specify
    // a duration of <= 10 ms. See gfxImageFrame::GetTimeout in Gecko or Radar 4051389 for more.
    if (duration <= 0.010)
        return 0.100;

[Alexey Proskuryakov]

http://nypop.com/~ap/webkit/mozchomp/mozchomp.html

According to this test, the behavior is:
IE 7/Win:
  <=50ms -> 100ms
  >50ms -> as specified
Opera 9.2/Mac:
  <100ms -> 100ms
  >=100ms -> as specified
Safari 2&3, Firefox 2:
  <=10ms -> 100ms
  >10ms -> as specified

[Alexey Proskuryakov]

Created attachment 15252 [details]
proposed fix

Comparing with 0.051 is needed because of floating point error, and is safe because GIF specifies timeouts in tens of milliseconds.

Please note that the test case still renders incorrectly on my machine - 100ms and 110ms images animate synchronously! This appears to be some unrelated timer-related issue: on a simpler page with just these two images left, the same images are animated correctly.

[Geoffrey Garen]

Comment on attachment 15252 [details]
proposed fix

r=me

Nice testing!

[Geoffrey Garen]

CC'ing Dave in case he disagrees. I believe he wrote the original code.

[Geoffrey Garen]

Do we need a new bug about the timer-related issue you've seen?

[Alexey Proskuryakov]

Committed revision 23821; filed bug 14432.

[Alexey Proskuryakov]

See also: <https://bugzilla.mozilla.org/show_bug.cgi?id=386269#c4> (it's not a given that Mozilla will follow IE behavior).

[Peter Kasting]

Firefox 3 shipped with the same behavior as past Firefox releases: <= 10 ms -> 100 ms.  As far as I know, they are the only browser to do this now, and I filed https://bugzilla.mozilla.org/show_bug.cgi?id=440882 about matching the other engines.  That said, I think Gecko's behavior, and WebKit's old behavior, is superior to WebKit's current behavior in the abstract, and if Gecko refuses to change, WebKit should seriously consider reverting this fix.

[Alexey Proskuryakov]

(In reply to comment #9)
> That said, I think Gecko's behavior, and WebKit's old behavior,
> is superior to WebKit's current behavior in the abstract, and if Gecko refuses
> to change, WebKit should seriously consider reverting this fix.

We are seriously considering that, see bug 36082. We don't have a consensus yet.