Web Animations API: Deferred computation of interpolated values

Web Animations API: Deferred computation of interpolated values

This change ensures animations created via element.animate() are
responsive to changes in the target element's style instead of animating
between "snapshot" values like the existing CSS animations and transitions.

Examples of responsive animation behaviour include:
- The current font size may change during an animation affecting all
  lengths defined using em/ex/rem units.
- The color may change affecting all keyframes that use currentcolor.
- Viewport resizes may change keyframes that use viewport units.
- The parent element style may change affecting keyframes that use inherit.

LegacyStyleInterpolation now defers the interpolation calculation to
animated style application time. This allows it to use the new RenderStyle
object to generate snapshots of the start and end keyframes to interpolate
between.

This behaviour is not ideal for performance or system coupling, as we
increase our coverage of CSSValues that can be converted to Interpolations
without the use of AnimatableValue we can move away from this pattern.
For now this is a catch all solution that provides the correct behaviour.

This patch is a continuation of ericwilliger's change:
https://codereview.chromium.org/261013006/

BUG=361948

[alancutter (OOO until 2018), 2014-05-08 12:34:12]

This change is a continuation of: https://codereview.chromium.org/261013006/

https://codereview.chromium.org/273683005/diff/1/Source/core/animation/String...
File Source/core/animation/StringKeyframe.cpp (right):

https://codereview.chromium.org/273683005/diff/1/Source/core/animation/String...
Source/core/animation/StringKeyframe.cpp:78: case CSSPropertyBorderTopWidth:
The border width properties can change value according to the value of the
current border style.
It's simpler to use LengthStyleInterpolation to be responsive here than to
complicate the late binding detection with this quirk.

[shans, 2014-05-08 16:12:57]

I'm really not that happy with this. It seems very awkward.

I'll have a think about whether we can do better, but right at the moment I
think the best thing to do would be to fall back to Eric's initial patch (the
two-sided late resolution):
https://codereview.chromium.org/239313013/patch/90001/100002, add your logic
from this path about when to use that path rather than the standard path, and
craft something more elegant after the branch.

You might need to pull some of the tests across too.

https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/In...
File Source/core/animation/InterpolableValuePromise.cpp (right):

https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/In...
Source/core/animation/InterpolableValuePromise.cpp:45: bool
InterpolableValuePromise::requiresLateBinding(const CSSPrimitiveValue&
primitiveValue)
I think we decided we should come up with a better name for this. In particular,
this isn't 'binding'.

https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/Le...
File Source/core/animation/LegacyStyleInterpolation.h (right):

https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/Le...
Source/core/animation/LegacyStyleInterpolation.h:17: static
PassRefPtrWillBeRawPtr<LegacyStyleInterpolation>
create(PassRefPtrWillBeRawPtr<AnimatableValue> start,
PassRefPtrWillBeRawPtr<AnimatableValue> end, CSSPropertyID id)
Why do we still have this? The point of InterpolableValuePromise was to abstract
away whether AnimatableValues or CSSValues were provided, I thought?

[alancutter (OOO until 2018), 2014-05-09 02:48:08]

On 2014/05/08 16:12:57, shans wrote:
> I'm really not that happy with this. It seems very awkward.
> 
> I'll have a think about whether we can do better, but right at the moment I
> think the best thing to do would be to fall back to Eric's initial patch (the
> two-sided late resolution):
> https://codereview.chromium.org/239313013/patch/90001/100002, add your logic
> from this path about when to use that path rather than the standard path, and
> craft something more elegant after the branch.
> 
> You might need to pull some of the tests across too.

Merged InterpolableValuePromise into LegacyStyleInterpolation.

> 
>
https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/In...
> File Source/core/animation/InterpolableValuePromise.cpp (right):
> 
>
https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/In...
> Source/core/animation/InterpolableValuePromise.cpp:45: bool
> InterpolableValuePromise::requiresLateBinding(const CSSPrimitiveValue&
> primitiveValue)
> I think we decided we should come up with a better name for this. In
particular,
> this isn't 'binding'.

Using interpolationRequiresStyleResolve instead.

>
https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/Le...
> File Source/core/animation/LegacyStyleInterpolation.h (right):
> 
>
https://codereview.chromium.org/273683005/diff/20001/Source/core/animation/Le...
> Source/core/animation/LegacyStyleInterpolation.h:17: static
> PassRefPtrWillBeRawPtr<LegacyStyleInterpolation>
> create(PassRefPtrWillBeRawPtr<AnimatableValue> start,
> PassRefPtrWillBeRawPtr<AnimatableValue> end, CSSPropertyID id)
> Why do we still have this? The point of InterpolableValuePromise was to
abstract
> away whether AnimatableValues or CSSValues were provided, I thought?

N/A.

[dstockwell, 2014-05-09 05:57:08]

I think this still isn't quite what Shane had in mind. It's also not compiling
currently, so I think we're going to have to defer this.

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/Le...
File Source/core/animation/LegacyStyleInterpolation.cpp (right):

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/Le...
Source/core/animation/LegacyStyleInterpolation.cpp:66: return false;
Which cases aren't handled here? Can this be a switch?

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/Le...
Source/core/animation/LegacyStyleInterpolation.cpp:75: return
lengthArray[CSSPrimitiveValue::UnitTypeFontSize]
Clearer to use != 0 here.

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/Le...
Source/core/animation/LegacyStyleInterpolation.cpp:82: ||
lengthArray[CSSPrimitiveValue::UnitTypeViewportMax];
Presumably this logic should live somewhere else? How does someone know to
update this when we add new units?

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/Le...
Source/core/animation/LegacyStyleInterpolation.cpp:116: default:
How do we avoid hitting other important cases?

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/cs...
File Source/core/animation/css/CSSAnimations.cpp (right):

https://codereview.chromium.org/273683005/diff/40001/Source/core/animation/cs...
Source/core/animation/css/CSSAnimations.cpp:446:
ASSERT(newFrames[0]->propertyValue(id));
This doesn't seem necessary. Or I don't understand it, why would
setPropertyValue not set the property value?