Web Animations: Trigger and update CSS Animations backed by the Web Animations model

Source/core/css/resolver/StyleResolver.cpp

Index: Source/core/css/resolver/StyleResolver.cpp
diff --git a/Source/core/css/resolver/StyleResolver.cpp b/Source/core/css/resolver/StyleResolver.cpp
index 30d450de65d64e0fb1d1e3ea882e79266044490c..616e1d72e569d12e59f0a6d647f4d17e7ba01db5 100644
--- a/Source/core/css/resolver/StyleResolver.cpp
+++ b/Source/core/css/resolver/StyleResolver.cpp
@@ -36,6 +36,7 @@
 #include "core/animation/AnimatableValue.h"
 #include "core/animation/Animation.h"
 #include "core/animation/DocumentTimeline.h"
+#include "core/animation/css/CSSAnimations.h"
 #include "core/css/CSSCalculationValue.h"
 #include "core/css/CSSDefaultStyleSheets.h"
 #include "core/css/CSSFontSelector.h"
@@ -623,6 +624,7 @@ PassRefPtr<RenderStyle> StyleResolver::styleForElement(Element* element, RenderS
 
 PassRefPtr<RenderStyle> StyleResolver::styleForKeyframe(Element* e, const RenderStyle* elementStyle, const StyleKeyframe* keyframe, KeyframeValue& keyframeValue)
 {
+    ASSERT(!RuntimeEnabledFeatures::webAnimationsCSSEnabled());
     ASSERT(document()->frame());
     ASSERT(documentSettings());
 
@@ -703,6 +705,39 @@ const StyleRuleKeyframes* StyleResolver::matchScopedKeyframesRule(Element* e, co
     return 0;
 }
 
+void StyleResolver::keyframeStylesForAnimation(Element* element, const StringImpl* name, KeyframeAnimationEffect::KeyframeVector& keyframes)

[dglazkov, 2013/07/29 18:15:39]

Not for this patch, but just curious: does this have to live on StyleResolver?
Could the logic that builds keyframes (and I am assuming later interpolates
styles between them) live in a separate class?

[dstockwell, 2013/07/30 01:12:48]

I think most of the logic can move out and I can work on that later. We'll just
need matchScopedKeyframesRule.

+{
+    ASSERT(RuntimeEnabledFeatures::webAnimationsCSSEnabled());
+
+    const StyleRuleKeyframes* keyframesRule = matchScopedKeyframesRule(element, name);
+    if (!keyframesRule)
+        return;
+
+    // Construct and populate the style for each keyframe
+    const Vector<RefPtr<StyleKeyframe> >& styleKeyframes = keyframesRule->keyframes();
+    for (unsigned i = 0; i < styleKeyframes.size(); ++i) {
+        const StyleKeyframe* styleKeyframe = styleKeyframes[i].get();
+
+        Vector<float> offsets;
+        styleKeyframe->getKeys(offsets);
+        for (size_t j = 0; j < offsets.size(); ++j) {
+            RefPtr<Keyframe> keyframe = Keyframe::create();
+            keyframe->setOffset(offsets[j]);
+            const StylePropertySet* properties = styleKeyframe->properties();
+            // FIXME: AnimatableValues should be shared between the keyframes at different offsets.
+            for (unsigned k = 0; k < properties->propertyCount(); k++) {
+                CSSPropertyID property = properties->propertyAt(k).id();
+                // FIXME: CSSValue needs to be resolved.
+                keyframe->setPropertyValue(property, AnimatableValue::create(properties->getPropertyCSSValue(property).get()).get());
+            }
+            keyframes.append(keyframe);
+        }
+    }
+
+    // FIXME: If the 0% keyframe is missing, create it (but only if there is at least one other keyframe)
+    // FIXME: If the 100% keyframe is missing, create it (but only if there is at least one other keyframe)
+}
+
 void StyleResolver::keyframeStylesForAnimation(Element* e, const RenderStyle* elementStyle, KeyframeList& list)
 {
     list.clear();
@@ -1190,7 +1225,7 @@ void StyleResolver::invalidateMatchedPropertiesCache()
 
 void StyleResolver::applyMatchedProperties(StyleResolverState& state, const MatchResult& matchResult)
 {
-    const Element* element = state.element();
+    Element* element = state.element();

[dglazkov, 2013/07/29 18:15:39]

Whoops. This seems wrong. We _just_ did a pass at trying to make Element
unaffected while resolving its style, and now we're mutating the element again?

[dstockwell, 2013/07/30 01:12:48]

The only mutation here is the call to ensureActiveAnimations. Perhaps making
that method const, or a cast on #1274 would be more palatable? 

     ASSERT(element);
     STYLE_STATS_ADD_MATCHED_PROPERTIES_SEARCH();
 
@@ -1231,7 +1266,14 @@ void StyleResolver::applyMatchedProperties(StyleResolverState& state, const Matc
     applyMatchedProperties<AnimationProperties>(state, matchResult, true, matchResult.ranges.firstAuthorRule, matchResult.ranges.lastAuthorRule, applyInheritedOnly);
     applyMatchedProperties<AnimationProperties>(state, matchResult, true, matchResult.ranges.firstUserRule, matchResult.ranges.lastUserRule, applyInheritedOnly);
     applyMatchedProperties<AnimationProperties>(state, matchResult, true, matchResult.ranges.firstUARule, matchResult.ranges.lastUARule, applyInheritedOnly);
-    // FIXME: animations should be triggered here
+
+    if (RuntimeEnabledFeatures::webAnimationsCSSEnabled()) {
+        const CSSAnimationDataList* animations = state.style()->animations();
+        EDisplay display = state.style()->display();
+        if ((display != NONE && animations && animations->size()) || element->hasActiveAnimations()) {
+            element->ensureActiveAnimations()->cssAnimations()->update(element, display, this, animations);

[dglazkov, 2013/07/29 18:15:39]

Curious: why does a DOM element hold information about animations? Doesn't this
belong in style-land somewhere?

[dstockwell, 2013/07/30 01:12:48]

I was going to store it in animation-land in a Map, but Elliott had concerns
(see https://codereview.chromium.org/19266007/)

For lifetime reasons Element seems like the next best place. CSS Animations are
started during style resolution, but end based on time, or element
detach/destruction.

In the current animation system this state lives in a Map from RenderObject, but
that fails to handle reattachment correctly.

ActiveAnimations currently only stores animations that are applied to the
RenderStyle, however it's likely that we will use it to store other DOM related
animation data (see
http://dev.w3.org/fxtf/web-animations/#extensions-to-the-element-interface).

Note also that in Web Animations, animations created by script (not CSS
Animations) will progress/fire events regardless of whether they have any effect
on the style of the element or even when the element is display:none (see
http://dev.w3.org/fxtf/web-animations/#timing-events). Animations or rather
Timed Items are not simply part of the style system.

[dglazkov, 2013/07/30 22:07:27]

I just spoke with shans@ about this, and I think we can fix this quite easily.
Let's break this into two phases:

1) constructing a new animation
2) adding this animation to element->activeAnimations.

If we do the first one at the applyProperties time, then queue it up, then pour
the queue into element->activeAnimations.

Queue would be stored on StyleResolverState

This would allow us to:
1) retain Element constness in applyProperties
2) clearly inform style machinery about effects of property application (a
similar thing happens for images, for example).
3) provide a path for future refactorings that may include multiple threads,
etc.

WDYT?

+        }
+    }
 
     // Now we have all of the matched rules in the appropriate order. Walk the rules and apply
     // high-priority properties first, i.e., those properties that other properties depend on.