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

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

 /*
  * Copyright (C) 2006 Samuel Weinig (sam.weinig@gmail.com)
  * Copyright (C) 2004, 2005, 2006, 2008 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
@@ skipping 25 matching lines @@
     , m_hasAlpha(true)
     , m_frameBytes(0)
 {
 }
 
 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