[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 #8 from Carlos Alberto Lopez Perez <clopez 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.

I think there are more issues here.

As I only can see an slow play the first time the GIF plays (for any of the examples: lightning or bigbuck5s.gif).

Once the first iteration loop is played, then the second (and posterior) iteration loops play perfectly fine.

I also tested to remove the LargeAnimationCutoff limit and there is no difference. Same behaviour than before.

-- 
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/20170925/20caa258/attachment-0001.html>