[Webkit-unassigned] [Bug 26455] New: GIF clamping time differs from Firefox

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26455

           Summary: GIF clamping time differs from Firefox
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pkasting at google.com
                CC: hyatt at apple.com, ap at webkit.org


On bug 14413 WebKit's GIF clamping algorithm was changed from "<= 10 ms -> 100
ms", which matches all versions of Firefox, to "<= 50 ms -> 100 ms", which
matches IE 6+.  There is a long discussion of the history of this clamping time
(in all browsers, though mainly Gecko-based ones) at
https://bugzilla.mozilla.org/show_bug.cgi?id=440882 .

This change has compatibility ramifications.  At I noted on that Mozilla bug,
some GIFs in the wild are clearly more correct with Firefox' lower clamping
time:

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

And some are clearly more correct in IE:

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

And some are not clear precisely which is better (in which case hopefully it
doesn't matter too much):

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

Anecdotally, Safari is widely seen to have "performance problems" with GIFs; a
search for "Safari animated GIFs" turns up pages like 
http://discussions.apple.com/thread.jspa?threadID=1229922 with comments like
"GIF support was perfect in Safari 2 but now they play half as slow as needed.
YTMND has been rendered useless!!!", which matches the implementation of the
more aggressive clamping on bug 14413.  (However, most problems reported
actually turn out to be either bug 19663 or bug 22280.)

In discussion on IRC Hyatt raised the following points:
* Abandoning IE compat is worrisome.
* There cannot be no clamp at all, at least in Safari, for similar reasons as
to setTimeout().
* Clamping "<= n ms -> n ms" makes more sense than raising low values all the
way to 100, however, this probably affects compat drastically (e.g. images that
have a frame time of 0 ms and expect to be played at 10 FPS)
* Clamping <= 50 ms == 20 FPS, which seems to aggressive in the abstract...
people ought to be able to do at least 60 FPS.

I think it is clear from the above samples that no matter what WebKit does some
GIFs will be incompatible.  From a purely abstract perspective, allowing people
to do > 20 FPS and in general respecting GIFs' frame times as much as possible
both seem like good things to me.  From a perception perspective, playing GIFs
too slow makes Safari/WebKit look slow and boggy in general, whereas playing
them too fast at least doesn't make people think "my browser is slow".  From an
anecdotal perspective, I have long heard more complaints about IE and Safari
(and experienced a number of too-slow images therein) than about Firefox.

I propose returning the clamp to "<= 10 ms -> 100 ms".  It is not perfect, but
I think it is a net win.

I can write a patch to do this easily, but I'd like to hear an explicit thumbs
up or down first.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.