[webkit-changes] [WebKit/WebKit] e9e959: [web-animations] composed keyframe animation behav...

[Antoine Quint]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e9e959922d195e8daa40a74c08f00fe06a615206
      https://github.com/WebKit/WebKit/commit/e9e959922d195e8daa40a74c08f00fe06a615206
  Author: Antoine Quint <graouts at webkit.org>
  Date:   2024-03-09 (Sat, 09 Mar 2024)

  Changed paths:
    M LayoutTests/platform/glib/TestExpectations
    M LayoutTests/webanimations/accelerated-animations-and-composite-expected.txt
    M LayoutTests/webanimations/accelerated-animations-and-composite.html
    A LayoutTests/webanimations/accelerated-animations-and-implicit-keyframes-expected.txt
    A LayoutTests/webanimations/accelerated-animations-and-implicit-keyframes.html
    M Source/WebCore/animation/BlendingKeyframes.cpp
    M Source/WebCore/animation/BlendingKeyframes.h
    M Source/WebCore/animation/KeyframeEffect.cpp
    M Source/WebCore/animation/KeyframeEffect.h
    M Source/WebCore/animation/KeyframeEffectStack.cpp

  Log Message:
  -----------
  [web-animations] composed keyframe animation behaves differently in Webkit than Firefox and Chrome
https://bugs.webkit.org/show_bug.cgi?id=269858
rdar://123777133

Reviewed by Dean Jackson.

The reported broken content for this bug used two animations targeting an accelerated property (`transform`)
and using an implicit keyframe in both cases. When we encounter an accelerated animation with an implicit
keyframe, we resolve the implicit keyframes using the underlying style.

In this case, this breaks the content because the underlying style should be used only for the first of the
two `transform` animations, and the second animation ought to use the output of the first animation to use as
its underlying value. Since that values will change for each animation frame, we have to not run accelerated
animations in this particular instance.

So we now analyze the effect stack in `KeyframeEffectStack::allowsAcceleration()` for a case where an effect
targets an accelerated property using an implicit keyframe when an effect lower down the stack is already
animating that property. If we find this to be the case, we disable acceleration throughout the stack.

Note that with threaded animation resolution, we are able to run this same scenario in the animation thread
because we correctly resolve an effect stack with implicit keyframes no matter the configuration. The code
path modified by this patch is not exercised when threaded animation resolution is enabled.

We add a new test devoted to testing implicit keyframes for accelerated properties and modify the existing
test for the `composite` property and acceleration to not contain implicit keyframes.

* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/webanimations/accelerated-animations-and-composite-expected.txt:
* LayoutTests/webanimations/accelerated-animations-and-composite.html:
* LayoutTests/webanimations/accelerated-animations-and-implicit-keyframes-expected.txt: Added.
* LayoutTests/webanimations/accelerated-animations-and-implicit-keyframes.html: Added.
* Source/WebCore/animation/BlendingKeyframes.cpp:
(WebCore::BlendingKeyframes::hasImplicitKeyframeForProperty const):
(WebCore::BlendingKeyframes::analyzeKeyframe):
* Source/WebCore/animation/BlendingKeyframes.h:
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::setBlendingKeyframes):
(WebCore::KeyframeEffect::analyzeAcceleratedProperties):
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/animation/KeyframeEffectStack.cpp:
(WebCore::KeyframeEffectStack::allowsAcceleration const):

Canonical link: https://commits.webkit.org/275887@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications