440882 - GIF throttling differs between Gecko, all other browsers

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Peter Kasting]

Gecko and all other browsers I've tested disagree on GIF animation speed throttling.  Either Gecko should match everyone else's behavior, or the other browsers should all change to follow Gecko's.

Animation throttling in Gecko has a long history; see bug 125137, bug 139677, bug 207059, bug 232769, and bug 386269.  I'm sure I missed some too.  The point is, any decision here should be made after understanding why things are the way they are.

My attempt to summarize why things are how they are is as follows:

* On bug 125137, an initial throttle of "<100 ms -> 100 ms" was implemented to match IE (5) Win at the time.  (No authoritative explanation for IE Win's behavior was attempted.)

* On bug 139677, people complained that IE Mac, Opera, and Safari did not throttle this way, and since the behavior seemed silly in the abstract, it should be changed.  Someone posited that the main reason for throttling was broken GIF creators that used 0 timeouts, so forcing "<=10 ms -> something" would address this without touching most legit uses.  No action was taken here before the bug was duped against bug 207059.

* On bug 207059, someone noted that IE (6)'s behavior had changed to "<=50 ms -> 100 ms", and noted that Opera (7)'s behavior was "<=10 ms -> 100 ms".  People agreed that Opera's more narrowly-targeted throttling was less weird and decided to change to that, since there seemed to be little agreement between browsers as to how this should work.

* On bug 232769, in response to a complaint that the new, lower minimum frame time resulted in animations that were too fast in Firefox relative to IE, bz pointed out the comment on bug 207059 that the minimum had dropped in IE 6 compared to 5, suggested it would continue to drop in the future, and thus that IE would eventually converge on Gecko's more sane throttle.  The bug was WONTFIXed.

* At some point, Opera changed their throttle to match IE 5 Win (<100 ms -> 100 ms).

* On https://bugs.webkit.org/show_bug.cgi?id=14413 , WebKit changed their behavior to follow IE (<=50 ms -> 100 ms).

* At a subsequent point, Opera changed their behavior to match IE and Safari (I think; I haven't tested this recently, I'm going off memory here).

* On bug 386269 someone noted Gecko's throttling had been broken for a while and recently fixed to work again.  In response Gecko was briefly changed to match WebKitand IE.  bz complained that the previous bugs on this demonstrated concrete cases where this broke sites and the committers had not done their homework.  The throttle was taken back out and Fx3 shipped with the same behavior as previous Gecko releases (<=10 ms -> 100 ms).

I think this last revert was too hasty.  My reading of the old bugs does not suggest that there are lots of sites broken by IE's throttle which work fine with Gecko's; rather, there is a lot of discussion of what behavior makes the most logical sense, and what other browsers do.  Firefox' original implementation of throttling, and subsequent change in the throttle behavior, were both made to be compatible with another existing browser, although in the case of the current behavior that browser was Opera 7 rather than the far-more-dominant IE 6, partly because the Opera behavior seemed saner.  And the idea that there are lots of websites that break with IE's throttle (or at least, more than with Firefox' current throttle) is hard to credit given IE's marketshare.

At this point, things are different than in years past: IE, Safari, and (I think) Opera all agree on their throttling behavior, and I see it as unlikely to change.  While I personally see Firefox' behavior as slightly better in the abstract, I would like to see browser consistency.  So I propose re-landing a change like that originally on bug 386269, and matching IE and WebKit.  If this is WONTFIX, then there needs to be dialog between Gecko folks and WebKit/Opera folks to agree that Gecko's behavior is superior, and change those others to match Gecko (and presumably hope Microsoft eventually follows suit).

Comment 1

[Boris Zbarsky [:bzbarsky]]

There were not "lots" of sites broken, but certainly there were complaints that particular images people were using on sites were animating incorrectly.

I think the right course of action here is to standardize this behavior (perhaps even as part of HTML5)... Which is the dialog thing, I guess.  ;)

Comment 2

[Peter Kasting]

Yes, none of your comments on other bugs really said there were "lots" of sites broken, which is what my comment 0 implies you said; sorry.

As-is, there are definitely GIFs that look wrong with either method, so whatever choice is made, someone will be unhappy.

I have added a comment on the (still closed) WebKit bug 14413 pointing at this bug.  I don't know if anyone will notice.

I can ask Hixie if this sort of thing is in scope for HTML5, but I really doubt it is.  I am not sure what standard it would fall under.

Comment 3

[Hixie (not reading bugmail)]

It's far out of scope for HTML5, but in the absence of anywhere else to specify this, we can always add it. What should it say? "Animated GIF images must be animated as described by the GIF specifications, with the exception that, for historical reasons, frame times that are less than or equal to 50ms should be treated as frame times of 100ms."?

Comment 4

[Peter Kasting]

If we wanted to spec the other browsers' behavior, that sounds right to me.  If we put Gecko's behavior in the spec (which, as I said, seems saner, and at least some GIFs online rely on), it will at least be leverage to convince the other browser makers to do what Gecko does.  Because fixing this in a GIF decoder is easy, the concern would be less that browsers couldn't make the change (and I'm sure WebKit and Opera quickly would) and more that the effects on the web in general are unclear.

Comment 5

[Peter Kasting]

I haven't been able to convince WebKit that moving away from matching IE in order to match Fx is a good thing.  In searching for GIFs to demonstrate the difference, I found that there were some that were clearly more correct in Firefox:

http://img5.imageshack.us/img5/2482/creepin.gif
http://img106.exs.cx/img106/2384/fattyfatfatfat8kd.gif
http://img18.exs.cx/img18/3766/w3is.gif

As well as some clearly more correct in IE:

http://img160.echo.cx/img160/5202/catsarejerks7rn.gif

As well as some where it's not clear which was more correct:

http://www.forumammo.com/cpg/albums/userpics/10062/stop-posting.gif
http://img.funnyanimatedgifs.net/img/450-elmo-rofl.gif

In the abstract, both Dave Hyatt and I agree that
* <=50 ms == 20 FPS which is too early to clamp
* <=10 ms -> 100 ms is weird, <=10 ms -> 10 ms would make more sense and match better with setTimeout()

However, the second is almost certainly needed for compat reasons (haven't tested to know for sure).

Comment 6

[Peter Kasting]

Filed https://bugs.webkit.org/show_bug.cgi?id=26455 in hopes of getting WebKit to match Fx (the reverse of this bug).

Comment 7

[Peter Kasting]

Tested Opera 11 against the testcases on the above WebKit bug and it matches Firefox.

I'm going to take another shot at convincing Apple to let me change WebKit.

Comment 8

[Peter Kasting]

WebKit changed in http://trac.webkit.org/changeset/73295 and the change hasn't been backed out, so I'm closing this.  Hopefully some day IE and Opera will change to match.