RESOLVED FIXED 247299
Incorrect paint of 'translate' property animation 
https://bugs.webkit.org/show_bug.cgi?id=247299
Summary Incorrect paint of 'translate' property animation
Andrew Shcherbyna
Reported 2022-10-31 17:14:06 PDT
Created attachment 463331 [details] Bug recorded Visit this sandbox in Safari: https://codesandbox.io/s/new-firefly-lb1s2e?file=/src/index.js Open it in the new tab (by some reason bug doesn't appear in the sandbox preview) Click "Animate" button. As I understand, overlapping of the element without translation with the element with first keyframe applied get's erased. For example if you'll specify '0px' as the first keyframe - animation will work correctly. If it will be '10px' - first 10px of the original element will be still shown during the animation. Setting element's transform property to any valid value fixes this behaviour.
Attachments
Bug recorded (30.33 KB, video/quicktime)
2022-10-31 17:14 PDT, Andrew Shcherbyna 		no flags
Details
Test (382 bytes, text/html)
2023-01-20 03:32 PST, Antoine Quint 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2022-11-07 16:15:20 PST
<rdar://problem/102064448>
Simon Fraser (smfr)
Comment 2 2022-11-15 13:56:47 PST
Looks like the repaint we issue when the animation starts (after the element has popped into a composting layer) uses a rectangle which is affected by the running animation.
Antoine Quint
Comment 3 2022-11-16 00:59:59 PST
Might be caused by bug 236019.
Antoine Quint
Comment 4 2023-01-18 08:52:36 PST
I wonder if this has anything to do with use of RenderStyle::hasTransform() which does not check for individual transform properties.
Antoine Quint
Comment 5 2023-01-20 01:59:28 PST
Or probably to do with KeyframeEffect::computeExtentOfTransformAnimation() not accounting for individual transform properties :(
Antoine Quint
Comment 6 2023-01-20 03:32:00 PST
Created attachment 464574 [details] Test
Antoine Quint
Comment 7 2023-01-20 03:58:09 PST
Making computeExtentOfTransformAnimation() run for "translate" and returning some large bounds for debugging purposes doesn't alter behavior here. I suppose this shouldn't be surprising as I believe that method is about computing layer overlap for compositing purposes while animations run.
Antoine Quint
Comment 8 2023-01-20 05:57:57 PST
One possible issue is that Styleable::isRunningAcceleratedTransformAnimation() only checks for "transform" animations. I'm not sure if this will fix the problem but that at least is definitely wrong.
Antoine Quint
Comment 9 2023-01-20 08:19:45 PST
Pull request: https://github.com/WebKit/WebKit/pull/8879
EWS
Comment 10 2023-01-21 14:01:37 PST
Committed 259173@main (f55528510521): <https://commits.webkit.org/259173@main> Reviewed commits have been landed. Closing PR #8879 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.