Summary: | GIF animation throttling is different from MSIE | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | tor | ||||
Component: | Images | Assignee: | Alexey Proskuryakov <ap> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, gavin.sharp, hyatt, mrowe | ||||
Priority: | P2 | ||||||
Version: | 523.x (Safari 3) | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
URL: | https://bugzilla.mozilla.org/skins/custom/images/mozchomp.gif | ||||||
Attachments: |
|
Description
tor
2007-06-26 09:47:45 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; 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 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 on attachment 15252 [details]
proposed fix
r=me
Nice testing!
CC'ing Dave in case he disagrees. I believe he wrote the original code. Do we need a new bug about the timer-related issue you've seen? See also: <https://bugzilla.mozilla.org/show_bug.cgi?id=386269#c4> (it's not a given that Mozilla will follow IE behavior). 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. (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. |