The change in <http://trac.webkit.org/projects/webkit/changeset/55039> for bug 35115 has caused animations to attempt to "catch up" if there is insufficient data to play through when they first attempt to animate. When loading a large animated GIF over a slow connection this often leads to the animation skipping to near the end before starting to play.
Bug 35115 doesn’t provide any information about what problem it is trying to fix. The ChangeLog from the commit is similarly lacking in information. Given the lack of details and the significant nature of the regression I’d like to roll out that change and have it be addressed in some other manner.
<rdar://problem/7673523>
(In reply to comment #1) > Bug 35115 doesn’t provide any information about what problem it is trying to > fix. The ChangeLog from the commit is similarly lacking in information. Given > the lack of details and the significant nature of the regression I’d like to > roll out that change and have it be addressed in some other manner. Seems like a good idea. Do we have a way to test these things yet?
(In reply to comment #3) > (In reply to comment #1) > > Bug 35115 doesn’t provide any information about what problem it is trying to > > fix. The ChangeLog from the commit is similarly lacking in information. Given > > the lack of details and the significant nature of the regression I’d like to > > roll out that change and have it be addressed in some other manner. Sounds reasonable to me. > Seems like a good idea. Do we have a way to test these things yet? We clearly need to invent some sort of test mechanism since this code keeps getting broken.
I'd be inclined to rollout first and ask questions later. May we can use canvas to test this stuff?
Rolled out in r55076. I’ll reopen bug 35115.
I am confused. The behavior you describe was the precise behavior the patch was designed to achieve. This isn't a bug. This behavior is necessary for sites such as YTMND which time animated GIFs to other elements such as audio.
Furthermore, you'll see the individual frames as soon as they come in during load. And this has been the behavior of animations ever since the original set of timing patches a couple of years ago, except for the problem fixed in bug 35065 which could erroneously cause the animation to hang for a long time at the beginning.
I'm also frustrated at comment 1, because I gave details on the fix bug 35115 makes on the original bug 35065 (in comment 4) that caused this regression, where I wanted to patch it, and you asked that I open a different bug instead, which I did, referring back to the original issue! So this isn't context free. And finally, even if the behavior here was truly a bug, the patch on bug 35115 only causes the timer to start before advancing from frame 1 to frame 2 -- rolling that out starts the timer before advancing frame 2 to frame 3, so you'll still see skipping in the same condition (namely, if multiple frames worth of data come in at once). Sadly none of you seem to be on IRC right now. Please ping me when you show up so we can discuss.