Prevent synchronous image change notifications during paint

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

Index: third_party/WebKit/Source/platform/graphics/BitmapImage.cpp
diff --git a/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp b/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp
index 2ee3e6e73bcae85c79f1218cfd3a65bb9d6da8c6..2f3b925fa0913a5cab7cee801239036ab77c9431 100644
--- a/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp
+++ b/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp
@@ -499,29 +499,12 @@ void BitmapImage::startAnimation(CatchUpAnimation catchUpIfNecessary)
             nextFrame = frameAfterNext;
         }
 
-        // Draw the next frame immediately.  Note that m_desiredFrameStartTime
+        // Post a task to advance the frame immediately. m_desiredFrameStartTime
         // may be in the past, meaning the next time through this function we'll
         // kick off the next advancement sooner than this frame's duration would
         // suggest.
-        if (internalAdvanceAnimation(false)) {
-            // The image region has been marked dirty, but once we return to our
-            // caller, draw() will clear it, and nothing will cause the
-            // animation to advance again.  We need to start the timer for the
-            // next frame running, or the animation can hang.  (Compare this
-            // with when advanceAnimation() is called, and the region is dirtied
-            // while draw() is not in the callstack, meaning draw() gets called
-            // to update the region and thus startAnimation() is reached again.)
-            // NOTE: For large images with slow or heavily-loaded systems,
-            // throwing away data as we go (see destroyDecodedData()) means we
-            // can spend so much time re-decoding data above that by the time we
-            // reach here we're behind again.  If we let startAnimation() run
-            // the catch-up code again, we can get long delays without painting
-            // as we race the timer, or even infinite recursion.  In this
-            // situation the best we can do is to simply change frames as fast
-            // as possible, so force startAnimation() to set a zero-delay timer
-            // and bail out if we're not caught up.
-            startAnimation(DoNotCatchUp);
-        }
+        m_frameTimer = adoptPtr(new Timer<BitmapImage>(this, &BitmapImage::advanceAnimationWithoutCatchUp));

[chrishtr, 2016/06/04 06:39:49]

It seems it might be possible for startAnimation() to be called again (via
draw() or some other call site) before
this timer fires. That seems bad..

[pdr., 2016/06/04 15:05:34]

It's safe because startAnimation bails out if there's an active timer.

+        m_frameTimer->startOneShot(0, BLINK_FROM_HERE);
     }
 }
 
@@ -568,6 +551,12 @@ void BitmapImage::advanceAnimation(Timer<BitmapImage>*)
     // startAnimation() again to keep the animation moving.
 }
 
+void BitmapImage::advanceAnimationWithoutCatchUp(Timer<BitmapImage>*)
+{
+    if (internalAdvanceAnimation(false))
+        startAnimation(DoNotCatchUp);
+}
+
 bool BitmapImage::internalAdvanceAnimation(bool skippingFrames)
 {
     // Stop the animation.