Bug 14413 - GIF animation throttling is different from MSIE
Summary: GIF animation throttling is different from MSIE
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Alexey Proskuryakov
URL: https://bugzilla.mozilla.org/skins/cu...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-26 09:47 PDT by tor
Modified: 2010-03-13 10:11 PST (History)
4 users (show)

See Also:


Attachments
proposed fix (1.52 KB, patch)
2007-06-26 11:23 PDT, Alexey Proskuryakov
ggaren: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tor 2007-06-26 09:47:45 PDT
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).
Comment 1 Alexey Proskuryakov 2007-06-26 10:01:13 PDT
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;
Comment 2 Alexey Proskuryakov 2007-06-26 10:50:26 PDT
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
Comment 3 Alexey Proskuryakov 2007-06-26 11:23:30 PDT
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.
Comment 4 Geoffrey Garen 2007-06-26 14:17:27 PDT
Comment on attachment 15252 [details]
proposed fix

r=me

Nice testing!
Comment 5 Geoffrey Garen 2007-06-26 14:18:05 PDT
CC'ing Dave in case he disagrees. I believe he wrote the original code.
Comment 6 Geoffrey Garen 2007-06-26 14:18:32 PDT
Do we need a new bug about the timer-related issue you've seen?
Comment 7 Alexey Proskuryakov 2007-06-27 10:23:27 PDT
Committed revision 23821; filed bug 14432.
Comment 8 Alexey Proskuryakov 2007-06-30 03:20:27 PDT
See also: <https://bugzilla.mozilla.org/show_bug.cgi?id=386269#c4> (it's not a given that Mozilla will follow IE behavior).
Comment 9 Peter Kasting 2008-06-20 16:54:02 PDT
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.
Comment 10 Alexey Proskuryakov 2010-03-13 10:11:25 PST
(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.