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

[bugzilla-daemon at webkit.org]

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

--- Comment #19 from Miguel Gomez <magomez at igalia.com> ---
(In reply to Zan Dobersek from comment #7)
> (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.

Perfectly explained Zan.

Currently the GIFImageReader cannot decode a frame that was already decoded. So when older frames get deleted from the cache and they have to be decoded again, the reader won't decode anything. This is why when clearing the cache the reader is being deleted as well, so it's able to re-decode already decoded frames. Without the reader deletion, if older frames are removed from the cache, when they are requested again to the reader nothing is returned from the decoder.

But as Zan explains, everytime the reader is re-created, it has to parse the whole animation data, and then it decodes all the frames until the requested one, and this gets more and more expensive as the animation grows.

I think I found a way to rewind the reader to be able to decode older frames without having to delete it. Let me test it carefully and I'll upload the patch.

-- 
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/20171003/7b82c4bf/attachment.html>