NEW 236397
[css-transforms] transform animation on SVG element jumps as it ends
https://bugs.webkit.org/show_bug.cgi?id=236397
Summary [css-transforms] transform animation on SVG element jumps as it ends
halifirien
Reported 2022-02-09 12:26:45 PST
Created attachment 451425 [details] matrix-transform-jump-demo using animate on svg <g> with matrix transform keyframes. It completes the animation to the wrong position - and then instantaneously jumps to the correct position.
Attachments
matrix-transform-jump-demo (2.31 KB, text/html)
2022-02-09 12:26 PST, halifirien
no flags
Slight reduced test (1.31 KB, text/html)
2022-02-10 09:57 PST, Antoine Quint
no flags
Radar WebKit Bug Importer
Comment 1 2022-02-10 09:11:32 PST
Antoine Quint
Comment 2 2022-02-10 09:57:24 PST
Created attachment 451558 [details] Slight reduced test I've reduced the test a bit to not visibly interpolate.
Antoine Quint
Comment 3 2022-02-10 11:42:00 PST
RenderStyle::applyTransform() gets called once at the beginning of the animation and once at the end. Logging transformOperations shows that it differs between the two calls while originTranslate is a zero point.
Antoine Quint
Comment 4 2022-02-10 11:52:34 PST
The first set of transformOperations doesn't match what is being provided to the animate() call.
Antoine Quint
Comment 5 2022-02-10 12:09:42 PST
The call to CSSPropertyAnimation::blendProperties() in KeyframeEffect::setAnimatedPropertiesInStyle() takes two identical transforms which are correct and generates an incorrect one.
Antoine Quint
Comment 6 2022-02-10 12:20:42 PST
This simple diff fixes the bug: diff --git a/Source/WebCore/animation/CSSPropertyAnimation.cpp b/Source/WebCore/animation/CSSPropertyAnimation.cpp index 217e768c131d..f7338e6ccc40 100644 --- a/Source/WebCore/animation/CSSPropertyAnimation.cpp +++ b/Source/WebCore/animation/CSSPropertyAnimation.cpp @@ -171,6 +171,9 @@ static inline TransformOperations blendFunc(const TransformOperations& from, con return resultOperations; } + if (from == to) + return from; + if (context.client->transformFunctionListsMatch()) return to.blendByMatchingOperations(from, context); return to.blendByUsingMatrixInterpolation(from, context, is<RenderBox>(context.client->renderer()) ? downcast<RenderBox>(*context.client->renderer()).borderBoxRect().size() : LayoutSize()); But I'm not sure if this is the best fix. On the one hand, this is probably a good thing to do in general, but it also feels like this might be hiding an issue further down in the blending code where we would also yield an incorrect result with non-equal matrices.
Antoine Quint
Comment 7 2022-02-10 12:27:36 PST
Also, this doesn't fix the original test.
Note You need to log in before you can comment on or make changes to this bug.