Animated WebP: Optimize decoding in case of seeking

Source/core/platform/image-decoders/ImageDecoder.cpp

Index: Source/core/platform/image-decoders/ImageDecoder.cpp
diff --git a/Source/core/platform/image-decoders/ImageDecoder.cpp b/Source/core/platform/image-decoders/ImageDecoder.cpp
index 917161f10527eb91c1636fd73868dfe04515499f..65ee260b91ed56fa263f9b9b669a70ab3ee327a4 100644
--- a/Source/core/platform/image-decoders/ImageDecoder.cpp
+++ b/Source/core/platform/image-decoders/ImageDecoder.cpp
@@ -152,7 +152,7 @@ void ImageDecoder::clearFrameBuffer(size_t frameIndex)
     m_frameBufferCache[frameIndex].clearPixelData();
 }
 
-size_t ImageDecoder::findRequiredPreviousFrame(size_t frameIndex)
+size_t ImageDecoder::findRequiredPreviousFrame(size_t frameIndex, bool frameRectIsOpaque)
 {
     ASSERT(frameIndex <= m_frameBufferCache.size());
     if (!frameIndex) {
@@ -160,6 +160,11 @@ size_t ImageDecoder::findRequiredPreviousFrame(size_t frameIndex)
         return notFound;
     }
 
+    const ImageFrame* const currBuffer = &m_frameBufferCache[frameIndex];
+    if ((frameRectIsOpaque || currBuffer->alphaBlendSource() == ImageFrame::BlendAtopBgcolor)
+        && currBuffer->originalFrameRect().contains(IntRect(IntPoint(), size())))

[Peter Kasting, 2013/08/22 20:04:36]

Nit: Since we clamp the frame rect to not extend outside the image, should this
just be an equality check instead of contains()?  Or do not all decoders enforce
that?  (Same question later on)

[urvang (Google), 2013/08/22 23:25:14]

Good question! I have wondered the same because all the code under
image-decoders/ seems to be using contains (this file itself at line#192,
GIFDecoder.cpp and WEBPImageDecoder.cpp).

Maybe this should all be changed to equality check in a separate patch? I just
feel that it would be good to check that there were no specific reasons for
doing this.

e.g. I see that u first used it in GIF decoder in this patch:
https://chromium.googlesource.com/chromium/blink/+/7263ed7d5fee2d0bf46e921840...
I know that this was long ago, but do you remember if there was a reason not to
use equality at the time?

[Peter Kasting, 2013/08/22 23:39:31]

I probably wasn't sure (as I'm still not sure, offhand) whether the GIF frames
were clamped to the image size.

[urvang (Google), 2013/08/23 00:13:35]

Yes, the frames are clamed to image size for GIF and WebP:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

+        return notFound;
+
     // The starting state for this frame depends on the previous frame's
     // disposal method.
     size_t prevFrame = frameIndex - 1;