[Webkit-unassigned] [Bug 176089] [GTK][WPE] Fix playback of GIFs

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Sep 22 01:51:32 PDT 2017


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

Zan Dobersek <zan at falconsigh.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zan at falconsigh.net

--- Comment #7 from Zan Dobersek <zan at falconsigh.net> ---
(In reply to Michael Catanzaro from comment #2)
> http://i.imgur.com/YSxwPUC.gif
> 

As the GIF is being played, newer and newer frames have to be decoded, originating from GIFImageDecoder::frameBufferAtIndex():
http://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.cpp#L104

BitmapImage independently enforces a 30MB limit for decoded image data in destroyDecodedDataIfNecessary(). Once that is hit, the frame buffer cache is wiped out for the BitmapImage's ImageSource and the associated GIFImageDecoder:
http://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/BitmapImage.cpp#L72
http://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/ImageSource.cpp#L66

In GIFImageDecoder::clearFrameBufferCache(), this also wipes out the associated GIFImageReader object:
http://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.cpp#L121

The problem manifests when subsequent GIFImageDecoder::decode() calls, now with a newly-created GIFImageReader, want to decode for GIFFullQuery, and it worsens when doing so for higher-index frames. This specific GIFImageReader::decode() call becomes expensive:
http://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.cpp#L327

After each GIFImageReader re-creation, the decoding in that object has to start over, which is then becoming increasingly expensive the further we go into the GIF playback.

The lightning GIF has 390 frames, and this destroy-and-recreate-GIFImageReader occurrence kicks in approximately every 25-26th frame. For last 5 occurrences (frames 262, 288, 314, 340, 366), this decoding blocks the main thread from ~900 up to ~1100 milliseconds every time, so yeah.

-- 
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/20170922/7c7ff14d/attachment.html>


More information about the webkit-unassigned mailing list