Bug 288402 – Scroll-driven Animations are Jittery on iOS

• Component: Animations
• Status: RESOLVED CONFIGURATION CHANGED

[Sebastian Markbåge]

See the attached video of a slow-mo shot of the example at https://scroll-driven-animations.style/demos/cover-to-fixed-header/css/

Notice how the image is updating at a different rate than the rest of the scroll. This appears to be an issue with pretty much all other scroll-driven animation demos as well.

This appears to only be an issue on iOS builds. This doesn't seem to be an issue on desktop Safari Technical Preview.

The repo from the video is from iOS 18.4 Beta on an iPhone 13.

[Sebastian Markbåge]

Created attachment 474324 [details]
Repro on iOS 18.4 Beta on iPhone 13.

[Sebastian Markbåge]

Actually it does appear it can happen on desktop too when it lags behind but it's not as apparent and doesn't seem to happen every time. Where as on iOS it's every time.

[yisibl]

Yes, I was able to reproduce the bug in Safari on the Apple M1 Pro.

[Sebastian Markbåge]

I think the general issue is that they're not always in sync. The main benefit of having built-in scroll-driven is so that it can remain in sync with the native scroll. Otherwise the JS solutions are fine and in this case it seems that the JS versions are even better for some reason.

[Sebastian Markbåge]

I think the general issue is that they're not always in sync. The main benefit of having built-in scroll-driven is so that it can remain in sync with the native scroll. Otherwise the JS solutions are fine and in this case it seems that the JS versions are even better for some reason.

[Radar WebKit Bug Importer]

<rdar://problem/146047632>

[Antoine Quint]

There appears to be performance issues specific to this page. Additionally, the code in the iOS 18.4 betas is fairly stale at this point, the feature has seen much development since then which you cannot test on iOS at this time, unless you build WebKit yourself. Safari Technology Preview on macOS is the most convenient way to test a state close to what is available on the main development branch.

[Sebastian Markbåge]

I get the same jittery effect on every scroll-driven example I’ve seen and all the ones I’ve built too. While the JS driven ones using touch events and requestAnimationFrame are smooth so shouldn’t be the rendering.

Do you have a scroll-driven example page that you’ve been testing that’s smooth that I can try to see if it’s just something on my end?

It might just be an old WebKit. I updated to iOS 18.4 Beta 2 (22E5216h) which still has the same issue but I’m not sure if they update the WebKit branch at all in those.

AFAIK, you can’t install WebKit for iOS devices as a non-Apple employee from source so I can’t really try it. I tried building WebKit for the iOS simulator but that breaks touch events for some reason.

[Sebastian Markbåge]

Are all scroll-driven animations main thread only in WebKit? Maybe that's related.

This demo has a check box where if you check "Add Jank" it adds some JS stalls.

https://scroll-driven-animations.style/demos/cover-flow/css/

In Chrome the scrolling remains smooth with that checkbox because this animation is done completely off the main JS thread, in the compositor thread, when Scroll-driven Animations are used.

In WebKit, even in the current Safari Technical Preview on desktop, this stalls.

I'd expect scroll-driven animations to be driven on the same thread as the actual scroll. Otherwise they suffer from this drift, jank and jitter.

[Antoine Quint]

Yes, Scroll-driven Animations are main thread only at the moment. I'm aware of this demo and how it illustrates how performance may suffer if much work is performed on the main thread (and also how animations may only be performed at 60Hz since this is the page rendering update cadence for main thread content). This is something we are definitely wanting to address and I have been working towards something called threaded animation resolution (bug 250970) for some time to have a unified system in the UI process (not the Web process) to run animations with our own logic, which would allow scroll-driven animations but also other types of time-based animations that we've historically not accelerated.

But going back to the demo for which this issue was originally reported, the animations would be performed on the main thread anyway given the mix of properties being animated.

On macOS at least, I haven't come across much content that suffer from running on the main thread alone, at least compared with a recent Chrome build. If you have examples, I would welcome individual bugs for them such that we may investigate as these may exhibit layout or rendering performance issues that we should fix. 

I believe you are right about building WebKit for iOS devices using tools available to people external to Apple. My mistake for suggesting you could do that. The many fixes made on the main branch for Scroll-driven Animations would not make it to the iOS 18.4 betas.

[Bramus]

> But going back to the demo for which this issue was originally reported, the animations would be performed on the main thread anyway given the mix of properties being animated.

It was on (the backlog of) my backlog to update the https://scroll-driven-animations.style/demos/cover-flow/css/ demo so that uses only animations that can run purely on the Compositor.

This has now been done:

- https://scroll-driven-animations.style/demos/cover-flow/css/ = Only animates `transform` of the `<img>`s
- https://scroll-driven-animations.style/demos/cover-flow/css/multiple = Animates `transform` of the `<img>`s + `z-index` on the `<li>`s. The latter runs on the Main Thread.

[Antoine Quint]

Bramus, I was talking about https://scroll-driven-animations.style/demos/cover-to-fixed-header/css/. But good to know about those changes.

[Antoine Quint]

To close the loop on https://scroll-driven-animations.style/demos/cover-to-fixed-header/css/, I just tested with a ToT WebKit build on an iPhone 12 Pro and performance was as expected, absolutely nothing like the recording shared by Sebastian.

Sebastian, just to be sure: was that recording at real speed, or was it slowed down? It's very choppy :)

[Antoine Quint]

While I understand you can't see for yourself, I suggest we close this bug for the time being, or perhaps Sebastian would prefer holding it until there is an iOS release out there with support for Scroll-driven Animations out of the box?

[Sebastian Markbåge]

The video recording is in slow motion yea to illustrate the point.

I guess before closing there’s two questions I have:

Is there anything that has landed recently that would impact this so much? I didn’t see many changes recently related to this.

Is there an example page that you would’ve expected to work fine beforehand?

Here’s another example you can test:

https://test-swipe-beta.vercel.app/nav.html

It’s kind of broken and not in a polished state. It also uses various techniques like css variables. It’s jittery mostly at the end when it slows down.

That also illustrates the other bug that reported because scrolling gets canceled. So you have to swipe once first to start it and then lift your finger and swipe again.

[Antoine Quint]

There had been tons of changes related to Scroll-driven Animations, and in WebKit at large, since the codebase branched from iOS 18.4. It would be time-consuming to pinpoint when this particular demo improved. I'll take a look at that other demo.

[Sebastian Markbåge]

I might just have too high expectations that this would feel like native but it’s not really until threaded animation resolution (bug 250970) is resolved with 120hz that it’ll feel really good.

[Antoine Quint]

I believe two issues are being conflated here:

1. updating the page rendering at 120Hz on Pro Motion devices such that "main thread" scroll-driven animations (and all animations) run at 120Hz

2. running scroll-driven animations targeting qualifying properties off the main thread, which is tracked by "threaded animation resolution" in WebKit

The original demo you posted about would not behave any different with "threaded animation resolution" as it would run on the main thread, so what you're asking about is 120Hz page rendering updates.

[Antoine Quint]

Note that you can enable 120Hz page rendering updates on Pro Motion hardware (both macOS and iOS) by _disabling_ the "Prefer Page Rendering Updates near 60fps" feature flag.

[Sebastian Markbåge]

Interesting. With that flag off all the examples feel way better. There are still some jittery cases but it’s covered up more by the extra frames I guess.

I didn’t expect the frame rate to make such a huge impact.

[Sebastian Markbåge]

I’m not too worried about case 1 where non-qualifying properties can run at 120hz. It would be nice to have the option but we’re used to work around it and come up with UIs that work by only modifying opacity and transforms. As long as it can work with View Transitions.

Just 2 would be a major improvement since for the first time it would be possible at all to update at 120hz based on a gesture.

[Sebastian Markbåge]

One thing that isn't clear to me is why it appears so much better on Mac even on older versions (e.g. Safari 18.3 (20620.2.4.11.5)). Even with the 60fps flag on.

[Antoine Quint]

We definitely want to run scroll-driven animations for qualifying properties off the main thread and at 120Hz on qualifying hardware, regardless of the "Prefer Page Rendering Updates near 60fps" flag.

One thing we could envision as well is to selectively opt into a higher page rendering update cadence while scrolling or during a scrolling deceleration animation (the scroll position animation after you've released the scrolling gesture) if the scroller in question is the source for scroll or view timelines. This way, main thread animations would get 120Hz updates.

You said "I didn’t expect the frame rate to make such a huge impact". I think people aren't all as susceptible to 60Hz vs. 120Hz rendering updates… personally I tend to really see the difference for the tail-end of a deceleration animation when increments are down to a single or half point and 120Hz can make things appear a lot smoother.

[Sebastian Markbåge]

I saw some people theorized that 60fps is less noticeable on OLED displays with lower response times. It helps smooth it out. That could explain why I didn't see the effect so pronounced on a MacBook Pro M1 which has OLED lower response times than iPhone and more modern MacBooks.

It's also an argument for why 120fps support is more important now than it used to be because it's just way more noticeable on newer displays.

I'm satisfied with these explanations for now though and you can close this issue or mark it dependent on bug 250970.

[Sebastian Markbåge]

120hz while actively scrolling seems like a great compromise too vs. battery life or whatever.