The animated GIF at <http://i135.photobucket.com/albums/q156/HITHAR/1438ch-1.gif> appears to play at half-speed in Safari when compared to Firefox. This animated GIF requests 40ms per frame (25fps). Firefox is clamping the frame delay on animated GIFs to 100ms if the requested delay is less than 10ms. WebKit is clamping to 100ms if the requested delay is less than 50ms We're playing this back at 10fps while Firefox plays it back at the expected 25fps. <rdar://problem/7689300>
Created attachment 50647 [details] Patch v1
Note that this is basically reverting what we did in bug 14413. It may still be appropriate to revisit the decisions made in 2007, although there is no evidence that the Web landscape changed much since then (in this regard, anyway). + ImageIO currently implements its own clamping of frame durations (<rdar://problem/7689297>) + which will result in this change having no observable effect on platforms where it is used + until an updated version of ImageIO becomes available. It's extremely unfortunate that we'll have different behavior across OS X versions if this patch goes in.
(In reply to comment #2) > Note that this is basically reverting what we did in bug 14413. It may still be > appropriate to revisit the decisions made in 2007, although there is no > evidence that the Web landscape changed much since then (in this regard, > anyway). It’s nearly 3 years later and Firefox is still using their lower clamping threshold. If there were compelling compatibility reasons for matching Internet Explorer I would expect that Firefox would have seen them and taken action. Opera has also since switched from matching Internet Explorer on this issue to matching Firefox. > + ImageIO currently implements its own clamping of frame durations > (<rdar://problem/7689297>) > + which will result in this change having no observable effect on > platforms where it is used > + until an updated version of ImageIO becomes available. > > It's extremely unfortunate that we'll have different behavior across OS X > versions if this patch goes in. We already have different behavior across Mac OS X versions. ImageIO in Tiger has no clamping, so it gets whatever behavior WebKit implements. ImageIO on Leopard clamps to 100ms. ImageIO on SnowLeopard currently clamps at 50ms. Future versions of ImageIO will not clamp at all, so it will be up to WebKit’s clamping. This means that once an updated version of ImageIO is available there will be no more difference between Mac OS X versions than we currently have.
(In reply to comment #3) > It’s nearly 3 years later and Firefox is still using their lower clamping > threshold. If there were compelling compatibility reasons for matching > Internet Explorer I would expect that Firefox would have seen them and taken > action. The action seems to have been WONTFIX, see <https://bugzilla.mozilla.org/show_bug.cgi?id=232769> and its many duplicates (some of them are duplicates of duplicates). The newest I could find was filed last month, <https://bugzilla.mozilla.org/show_bug.cgi?id=544077>.
I made a couple experiments. First, it was very easy to find examples of animated gifs that were obviously too fast in Firefox. I could find such intentionally, and I also encountered them on sites I browse daily. This was all in a few minutes of testing. Second, I searched the Web for "IE animates gif too slow" and "Firefox animates gif too fast". The number of complaints was roughly the same. This tells me that on the grounds of Web compatibility, we shouldn't be making any sudden movements. Replacing a number of old bugs with an equal number of regressions is a loss.
I've done extensive research on this issue. Please see bug 26455, especially comment 0. The most relevant Mozilla bug, noted there, is https://bugzilla.mozilla.org/show_bug.cgi?id=440882 . As noted above, I believe the one factual update since I filed that bug is that Opera has changed (yet again) back to matching Firefox. My personal preference is to change to match Firefox' behavior, which I think is much more sensible. As ap notes, there are GIFs on the web that are broken no matter what you do, and the linked bug points out examples of both kinds (as well as images where the right speed is unclear). Given this, the fact that it is impossible to do standard-frame-rate animations with the IE clamp, and the fact that the IE clamp is a larger deviation from "no clamp", are what swing my opinion. Authors can conceivably update images that are too fast in Firefox to look right everywhere, but they can't make a similar change to make images too slow in IE look right everywhere. Another point: if we're going to look wrong on some images, I'd rather look like we're too fast than too slow, since the latter makes people think we're underperformant. To be honest, I think even better would be to clamp <= 10 ms to 10 ms, instead of 100. This is closer to what setTimeout() does. I suspect that we might be able to get the Mozilla folks to agree to this if we change to match them in the meantime. So, in short: I suggest duping against bug 26455 (or the other way around), landing this patch + changing any other similar instances in other graphics backends' code, and noting on the Mozilla bug that now all the browsers are united in the Firefox way except for IE. I asked Hixie at one point if this kind of thing could be specced in HTML5 and he suggested it wasn't a very great fit there, but perhaps we would still have the opportunity then to drop a note to the folks at Microsoft to suggest changing IE 9+.
Comment on attachment 50647 [details] Patch v1 The discussion seems to have dried up, so I'm saying r- to avoid it going in rounds. We certainly have a significant Web compatibility problem to solve, but as indicated by the research above, this particular solution will introduce an equal number of regressions, which is simply not how the WebKit project rolls. Perhaps - and hopefully - there is a clever heuristic we could come up with that would make it a clear win for existing Web content. > Authors can conceivably update images that are too fast in Firefox to > look right everywhere, but they can't make a similar change to make images too > slow in IE look right everywhere. Animated GIFs are a legacy technology, and making it learn new tricks is not the main concern - especially since these tricks won't be available for general Web content unless MS decides to make the same change, and until the versions of IE with the old behavior can be disregarded. There are many other ways to display animations on the Web.
These bugs have comparable amount of comments and insight, so I'm duping to the old one. *** This bug has been marked as a duplicate of bug 26455 ***
(In reply to comment #6) > To be honest, I think even better would be to clamp <= 10 ms to 10 ms, instead > of 100. But then a delay of 0 becomes 100 fps but in the past it has always been 10 fps in all browsers, right?
(In reply to comment #9) > (In reply to comment #6) > > To be honest, I think even better would be to clamp <= 10 ms to 10 ms, instead > > of 100. > > But then a delay of 0 becomes 100 fps but in the past it has always been 10 fps > in all browsers, right? Yes. The goal of that proposal would be sane behavior over backwards compatibility. I don't expect it to happen because I don't expect enough other people to agree with me.