Created attachment 429862 [details] Screen recording Steps to reproduce: 1. Open https://smartslider3.com/bugs/webkit/opacity0dropfps/ Expected result: FPS should be consistent during the animation Actual result: When the SVG becomes visible from opacity(opacity:0 and then in the next frame gets bigger than 0) cause the animation to feel sluggish as probably rendering of the resource allocate the main thread. Workaround: use non-zero small opacity like 0.1 for starting point. Able to reproduce: iPad 14.5.1 iPhone 14.6
It's possible that not opacity:0 itself cause this issue as we add visiblity:hidden to the elements which has opacity:0. So the cause could be that visibility:hidden changes to visibility:visible. [data-force-hidden], [data-force-hidden] * { visibility: hidden!important; }
I can reproduce on iPhone 12 Pro; animates smoothly on a Mac.
The SVG takes over 500ms to render on iPhone 7 Plus because of the filters (largely the gaussian blur). There's a layering change when opacity and/or transform transitions finish, which triggers a second paint of the SVG which is the visible stall. Some `will-change:` should fix this. Or you could remove the filters, since (in this example at least) they don't do anything visible.
<rdar://problem/78601603>
Thank you Simon, you are right. We dropped those filters and used filter="drop-shadow(...)" on the path and everything is the same. What is the tool what you used to find that it takes 500ms to render that SVG? Is it a tool in Safari(Mac) what I could use during remote debug of the real device?
I used some internal instrumentation, but I think attaching with Web Inspector and collecting a timeline recording would show you some long paints.
Created attachment 430045 [details] Long paints in timeline