High CPU and increased memory usage fix for high-res (GIF, WEBP...) animations.

third_party/WebKit/Source/platform/graphics/FrameData.cpp

Index: third_party/WebKit/Source/platform/graphics/FrameData.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/FrameData.cpp b/third_party/WebKit/Source/platform/graphics/FrameData.cpp
index b510aa935bccb53d3144cc6f4a3e9a5ac7cb0e2e..3edfe4f745baada4d323a970118b43745df95249 100644
--- a/third_party/WebKit/Source/platform/graphics/FrameData.cpp
+++ b/third_party/WebKit/Source/platform/graphics/FrameData.cpp
@@ -43,19 +43,13 @@ FrameData::~FrameData()
     clear(true);
 }
 
-bool FrameData::clear(bool clearMetadata)
+void FrameData::clear(bool clearMetadata)
 {
     if (clearMetadata)
         m_haveMetadata = false;

[Peter Kasting, 2016/05/04 03:01:07]

I wonder if m_haveMetadata buys much anymore.  Seems like it used to help
distinguish between when we'd decoded but thrown away the frame bitmap, and when
we hadn't decoded.  But now since we never have a frame bitmap, it seems like
this field could just disappear, and users of this object could just have a
FrameData object or not...

Though I guess that would mean a Vector<FrameData> would have to become a
Vector<std::unique_ptr<FrameData>>, which is probably worse.  So maybe this
should stay but just become m_initialized or something?

[Peter Kasting, 2016/05/07 01:58:29]

Did you have any thoughts on all this?

[aleksandar.stojiljkovic, 2016/05/07 19:50:53]

I agree that current m_haveMetadata is better than
Vector<std::unique_ptr<FrameData>>:
- it doesn't require additional space (as with other bit flags here occupies
total one sizeof(size_t).
- don't know if there is a way to have placement new with unique_ptr but don't
like redirecting to frame data allocated in non adjacent locations on the heap
when enumerating through all frames. Don't want to oversell this either - first
argument with "no space required" looks strong enough.

About m_haveMetadata vs m_initialized - don't have strong opinion.
m_haveMetadata makes more sense now then before since now we have no
RefPtr<SkImage> in FrameData but only m_uniqueID which is metadata (and
RefPtr<SkImage> m_frame wasn't).
In following patches I would suggest to remove all of this and getting the data
from the source.

 
     m_orientation = DefaultImageOrientation;
     m_frameBytes = 0;
-
-    if (m_frame) {
-        m_frame.clear();
-        return true;
-    }
-    return false;
 }
 
 } // namespace blink