[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