Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e9e959922d195e8daa40a74c08f00fe06a615206
https://github.com/WebKit/WebKit/commit/e9e959922d195e8daa40a74c08f00fe06a615206
Author: Antoine Quint <grao...@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
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
