Fixes webkitRequestAnimationFrame on windows

It appears that PostDelayedTask on windows is firing a bit earlier than this code expects.  This patch adds logic to reschedule a second timer if this occurs and adds a log.

BUG=70992
TEST=

Review URL: http://codereview.chromium.org/6391007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@73051 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 18 insertions, 4 deletions

diff --git a/chrome/renderer/render_widget.cc b/chrome/renderer/render_widget.cc
index 8fb1d55..5f66e49 100644
--- a/chrome/renderer/render_widget.cc
+++ b/chrome/renderer/render_widget.cc
@@ -488,10 +488,24 @@ void RenderWidget::CallDoDeferredUpdate() {
 }
 
 void RenderWidget::UpdateAnimationsIfNeeded() {
-  if (!is_hidden() && animation_update_pending_ &&
-      base::Time::Now() > animation_floor_time_) {
-    animation_update_pending_ = false;
-    webwidget_->animate();
+  if (!is_hidden() && animation_update_pending_) {
+    base::Time now = base::Time::Now();
+    if (now >= animation_floor_time_) {
+       animation_update_pending_ = false;
+       webwidget_->animate();
+    } else {
+      // This code uses base::Time::Now() to calculate the floor and next fire
+      // time because javascript's Date object uses base::Time::Now().  The
+      // message loop uses base::TimeTicks, which on windows can have a
+      // different granularity than base::Time.
+      // The upshot of all this is that this function might be called before
+      // base::Time::Now() has advanced past the animation_floor_time_.  To
+      // avoid exposing this delay to javascript, we keep posting delayed
+      // tasks until we observe base::Time::Now() advancing far enough.
+      int64 delay = (animation_floor_time_ - now).InMillisecondsRoundedUp();
+      MessageLoop::current()->PostDelayedTask(FROM_HERE, NewRunnableMethod(
+          this, &RenderWidget::UpdateAnimationsIfNeeded), delay);
+    }
   }
 }