Bug 210526 – WebAnimations API doesn't properly apply keyframe easings to transforms

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Alan Orozco]

Created attachment 396484 [details]
Safari (incorrect): Left box is animated with `top`. Right box is animated using `transform`. Both have the same keyframe easings.

Overview:

Animation effect definitions may include easing properties in each keyframe, like so:

  element.animate(
    [
      {
        top: "0px",
        easing: "step-start"
      },
      {
        top: "100px",
        easing: "step-start"
      },
      {
        top: "0px",
      }
    ],
    1000
  );

These should define the timing of interpolations between frames, but the
property is ignored when the keyframes include transforms.

Steps to reproduce:

Define an animation effect using a) transforms and b) easings per-keyframe.
An example is hosted here: https://webkit-animation-easing.glitch.me/easing.html

  element.animate(
    [
      {
        transform: "translateY(0px)",
        easing: "step-start"
      },
      {
        transform: "translateY(100px)",
        easing: "step-start"
      },
      {
        transform: "translateY(0px)",
      }
    ],
    1000
  );

Actual Results:

See in example URL that keyframe easings are not respected for the element
whose `transform` is animated.

Expected results:

Animation effect should respect easings, like it does for the element whose
`top` is animated.

Platform:

Safari Version 13.1 (15609.1.20.111.8)
macOS 10.15.4 (19E266)

Additional Information:

Attached video showing actual result.

[Alan Orozco]

Created attachment 396485 [details]
(ignore this attachment, it was added accidentally)

[Radar WebKit Bug Importer]

<rdar://problem/61800424>

[Alan Orozco]

Created attachment 396488 [details]
Chrome (correct): Left box is animated with `top`. Right box is animated using `transform`. Both have the same keyframe easings.

[Antoine Quint]

We don't support the "steps" family of timing functions for accelerated animations. We should opt out of the accelerated path in that case.

[Antoine Quint]

Created attachment 396538 [details]
Test showing CSS and Web Animations for top and transform

Attaching a new test case that shows how CSS Animations behave correctly but not a JS-originated animation.

[Antoine Quint]

I think we're not setting the per-keyframe timing functions in KeyframeEffect::updateBlendingKeyframes().

[Antoine Quint]

Created attachment 396965 [details]
Patch

[Antoine Quint]

Committed r260360: <https://trac.webkit.org/changeset/260360>

[Antti Koivisto]

Comment on attachment 396965 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=396965&action=review

> LayoutTests/webanimations/transform-animation-with-steps-timing-function-not-accelerated.html:23
> +    animation.ready.then(() => {
> +        // We wait for two frames to ensure an accelerated animation would have been committed.
> +        requestAnimationFrame(() => {
> +            requestAnimationFrame(() => {
> +                assert_equals(internals.acceleratedAnimationsForElement(target).length, 0, "The animation's target has no accelerated animation.");
> +                t.done();
> +            });
> +        });
> +    });

This would read better with await

[Antoine Quint]

*** Bug 212686 has been marked as a duplicate of this bug. ***

[Antoine Quint]

This caused bug 213495.