[Webkit-unassigned] [Bug 98285] Improve image decoding and rendering performance for animated GIFs

[bugzilla-daemon at webkit.org]

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





--- Comment #4 from Peter Kasting <pkasting at google.com>  2012-10-29 17:05:04 PST ---
(In reply to comment #3)
> > This all seems untrue.  The clear-before-frame logic is precisely how we implement keeping just the most recent frames, so it's not the case that it "doesn't do much".  I don't see how it's overly complicated (for what it needs to do) or makes frame skipping hard, either.
> 
> I probably has a bad understanding of what this logic does. My point is to have this logic of "keep the last frame necessary" exist only in the decoder. clearFrameBufferCache(clearBeforeFrame) is always called with clearBeforeFrame = currentFrame, would it be simpler to just have a clearFramesBeforeLast() method? In the API level this doesn't give control of what frames to be cleared to users of the GIF decoder.
> 
> Under the hood GIFImageDecoder is still doing what's doing now and this will be a simple API change.

But the decoder doesn't know what frame the BitmapImage is on.  (It isn't guaranteed to be the same as the decoder's last frame.)

> > (5) We should extend the frame metadata to save the byte offsets within the file at which each frame begins.  This way, decode passes 2+ can avoid having to parse anything out of the file to skip through it.
> 
> This is the same optimizations I listed in (2) but a different implementation.
> 
> Instead of saving this byte offsets as metadata in BitmapImage and destroy ImageDecoder I suggest we push the handling of clear(destroyAll = true) down to each decoder. For formats other than GIF this can be implemented by destroying the corresponding ImageReader. For GIF it handles by keeping a copy of frame offsets. I think this optimization of saving byte offsets is specific to GIF and should be kept in GIFImageDecoder.

But there isn't a separate reader class for some of these types.  And the decoder carries around state that is needless and wastes memory.

Plus formats like ICO have multiple frames and could thus use the frame offsets too, to avoid re-parsing the header.

Our frame metadata already carries enough other state that I don't see adding this as problematic.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.