The latter example (3d-shoe-explorer) is not expected to run on the compositor; the shoes are threejs scenes (<model-viewer>) and not rendered by css; their rotation is “synced” with the scroll-timeline progress using a requestAnimationFrame loop, which is capped at 60hz in Safari. However, the first example (cover-flow) seems to me like it should, in principle, be compositor-only and unaffected by blocking the main thread.

Paul, scroll-driven animations don't have any acceleration support in Safari at the moment. This will be added as part of bug 250970. As such I will mark this bug as a duplicate. It is indeed expected until we have threaded animation resolution implemented that https://scroll-driven-animations.style/demos/cover-flow/css/ with the "Add jank" option enabled will have jank. If you see performance issues in other demos, please file issues specific to each of them as it is my expectation that on macOS, Safari should match or exceed or Chrome's performance for the demos on https://scroll-driven-animations.style. *** This bug has been marked as a duplicate of bug 250970 ***

Before “threaded animation resolution” lands, is it expected that scroll animations will run at 60hz or 120hz? Looking at https://scroll-driven-animations.style/demos/reverse-scroll/css/ on a ProMotion screen it appears that the scroll-animation-driven reverse-scrolling items are updated at half the frame rate / “smoothness” that the native-scrolling ones are.

Scroll-driven Animations will update at the same cadence as all other page rendering updates, which is 60Hz by default on ProMotion displays. This is true not just for non-accelerated animations, but all page rendering, including requestAnimationFrame callbacks. The feature flag "Prefer Page Rendering Updates near 60fps" can be disabled to have that cadence set to 120Hz on a device equipped with a ProMotion display.