Move GIF decoder's aggressive purge into ImageDecoder

third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp

Index: third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
diff --git a/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp b/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
index 1e3bb065585d9268f58c58bb34233b98073cfdd1..f9b63c98e1ddf3bd6ef991c4becd547bb0f2242b 100644
--- a/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
+++ b/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
@@ -240,6 +240,41 @@ void ImageDecoder::clearFrameBuffer(size_t frameIndex)
     m_frameBufferCache[frameIndex].clearPixelData();
 }
 
+void ImageDecoder::updateAggressivePurging(size_t index)
+{
+    if (m_purgeAggressively)

[urvang, 2016/10/03 19:18:06]

So, once we set m_purgeAggressively to true, we'll never set it to false. I
wonder if that is the behavior we want.
(Of course, this patch is just for moving code, so any change to behavior
belongs in a separate patch. But I'm just thinking aloud here.)

[cblume, 2016/10/03 19:39:19]

I believe it is.

Ideally, this would be set once at the very beginning. But we don't have all the
data at the very beginning and cannot make the decision until we have enough
information.

But the point of it is: If we do not have space, we won't ever have space. We'll
never suddenly consume less of the memory budget. The image only ever grows
larger as more data comes in / we decode and find there are more frames.

[urvang, 2016/10/03 19:56:07]

We call "if (m_purgeAggressively) clearCacheExceptFrame(*i);" at some point. So,
at that point, all except one frame will be cleared from memory. And memory
would be free again to cache some frames, right?

[cblume, 2016/10/03 20:05:35]

You are correct. What I mean is we wouldn't have space for all of the frames.

If all of the frames fit within our memory limit, then we shouldn't purge them*.
But if they wouldn't fit, we need to purge things anyway.

So we keep the keyframe we will need for the next frame to decode. But we purge
the rest.


*Outside of the ImageDecoder, Blink/CC just purges after every frame anyway. So
even though we could keep it all in memory, Chrome doesn't. This is just a bad
design that we're fixing. The root problem is every image has its own budget.
They should be part of a shared image budget.

+        return;
+
+    // We don't want to cache so much that we cause a memory issue.
+    //
+    // If we used a LRU cache we would fill it and then on next animation loop
+    // we would need to decode all the frames again -- the LRU would give no
+    // benefit and would consume more memory.
+    // So instead, simply purge unused frames if caching all of the frames of
+    // the image would use more memory than the image decoder is allowed
+    // (m_maxDecodedBytes) or would overflow 32 bits..
+    //
+    // As we decode we will learn the total number of frames, and thus total
+    // possible image memory used.
+
+    const uint64_t frameArea = decodedSize().area();
+    const uint64_t frameMemoryUsage = frameArea * 4; // 4 bytes per pixel
+    if (frameMemoryUsage / 4 != frameArea) { // overflow occurred
+        m_purgeAggressively = true;
+        return;
+    }
+
+    const uint64_t totalMemoryUsage = frameMemoryUsage * index;
+    if (totalMemoryUsage / frameMemoryUsage != index) { // overflow occurred
+        m_purgeAggressively = true;
+        return;
+    }
+
+    if (totalMemoryUsage > m_maxDecodedBytes) {
+        m_purgeAggressively = true;
+    }
+}
+
 size_t ImageDecoder::findRequiredPreviousFrame(size_t frameIndex, bool frameRectIsOpaque)
 {
     ASSERT(frameIndex <= m_frameBufferCache.size());