[Webkit-unassigned] [Bug 183153] Animated GIF imagery with finite looping are falling one loop short

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 12 11:43:24 PDT 2018


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

--- Comment #3 from Said Abou-Hallawa <sabouhallawa at apple.com> ---
I am not convinced that the Chrome behavior and the old Safari are correct.

I opened the attached GIF file as a binary file and I can confirm that the loop count saved in this file is 2. I attached a screenshot showing the image in its binary format. The screenshot highlights the Netscape Looping Application Extension block. The red rectangle is the 2 bytes (the second and the third bytes from the end) representing the animation loop count.

I tried hard to find a detailed description for the Netscape Looping Application Extension block but I could not find enough information. The W3C specs https://www.w3.org/Graphics/GIF/spec-gif89a.txt does not mention it. Wikipedia https://en.wikipedia.org/wiki/GIF has some info but not it is enough. I found this link  http://www.vurdalakov.net/misc/gif/netscape-looping-application-extension useful and it matches what I see in the attached screenshot. But neither this page nor the Wikipedia says that we need to animate the GIF image one extra iteration if the LoopCount is not zero.

What Chrome does to fix this issue was to increment the repetitionCount by 1 if the loopCount is not equal to zero. And this is what WebKit was doing in the past. See the comment above cAnimationLoopOnce from this link: https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/ImageSource.h?rev=198655.

Also the APNG file format https://wiki.mozilla.org/APNG_Specification does not say, the image should be animated (num_plays + 1) if num_plays is not equal to zero. I think this because APNG does not special case the num_plays == 1 as the GIF does. The GIF image does not include the loopCount in the Netscape Looping Application Extension block if it is equal to 1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180412/84905b40/attachment-0002.html>


More information about the webkit-unassigned mailing list