Defer starting of animations until after compositing update

Source/core/animation/DocumentAnimations.cpp

 /*
  * Copyright (C) 2013 Google 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:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 32 matching lines @@
 #include "core/rendering/RenderView.h"
 
 namespace WebCore {
 
 namespace {
 
 void updateAnimationTiming(Document& document)
 {
     document.timeline()->serviceAnimations();
     document.transitionTimeline()->serviceAnimations();
-    if (!document.childNeedsStyleRecalc())
-        document.animationClock().unfreeze();
 }
 
 void dispatchAnimationEvents(Document& document)
 {
     document.timeline()->dispatchEvents();
     document.transitionTimeline()->dispatchEvents();
 }
 
 void dispatchAnimationEventsAsync(Document& document)
 {
     document.timeline()->dispatchEventsAsync();
     document.transitionTimeline()->dispatchEventsAsync();
 }
 
 } // namespace
 
-void DocumentAnimations::serviceOnAnimationFrame(Document& document, double monotonicAnimationStartTime)
+void DocumentAnimations::serviceOnFrameStart(Document& document, double monotonicAnimationStartTime)
 {
+    // FIXME: This seems fragile. Do we need a separate frame lifecycle?
+    ASSERT(document.lifecycle().state() == DocumentLifecycle::StyleClean || document.lifecycle().state() == DocumentLifecycle::StyleRecalcPending || document.lifecycle().state() == DocumentLifecycle::LayoutClean || document.lifecycle().state() == DocumentLifecycle::CompositingClean);

[abarth-chromium, 2014/02/20 17:52:00]

What are you trying to assert here?  As written, this line of code doesn't make
sense.  If you write out what you're trying to assert in an english sentence, we
can figure out how to translate that into code.

[dstockwell, 2014/02/20 18:22:01]

I was looking at what we know about the beginning of a frame. When cc calls
animate we can be in any of these states.

Between the calls to animate and layout the DocumentLifecycle can traverse the
style/layout related states several times. We don't have a good way of knowing
where we are in the process of making a single frame.

     document.animationClock().updateTime(monotonicAnimationStartTime);
     updateAnimationTiming(document);
     dispatchAnimationEvents(document);
 }
 
 void DocumentAnimations::serviceBeforeGetComputedStyle(Node& node, CSSPropertyID property)
 {
     if (!node.isElementNode())
         return;
     const Element& element = toElement(node);
     if (element.document().timeline()->hasOutdatedPlayer()) {
         updateAnimationTiming(element.document());
         return;
     }
     if (const ActiveAnimations* activeAnimations = element.activeAnimations()) {
         if (activeAnimations->hasActiveAnimationsOnCompositor(property))
             updateAnimationTiming(element.document());
     }
 }
 
-void DocumentAnimations::serviceAfterStyleRecalc(Document& document)
+void DocumentAnimations::serviceOnFrameEnd(Document& document)
 {
+    ASSERT(document.lifecycle().state() == DocumentLifecycle::CompositingClean);
     if (document.cssPendingAnimations().startPendingAnimations() && document.view())
         document.view()->scheduleAnimation();
 
     document.animationClock().unfreeze();
     dispatchAnimationEventsAsync(document);
 }
 
 } // namespace WebCore