You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I haven't checked any of the data you provided in detail, but it is expected that the polyfill runs slower than a native implementation.
This because native implementations can run these animations on the compositor, whereas this polyfill runs JavaScript on the main tread to adjust the animations.
I imagine that a native implementation would indeed perform better since it can leverage the compositor for animations. However, what's strange is that the polyfill runs smoothly on Firefox similar to native Chrome but stutters noticeably on Safari. This inconsistency is puzzling, as I'd expect similar performance issues across browsers when using JavaScript on the main thread.
i believe it is because safari tries renders the element opposite direction of the scroll, so it looks laggy, nothing to do about performance, but about synchronizing transform of elements with the safari's own render timing. could be (not 100% sure) fixed with using a requestAnimationFrame to update transform of elements.
I've been playing around with the Polyfill and integrated it with the "Reverse Scroll" demo by Bramus available: here
While the Polyfill works as expected in Chrome (native behavior) and Firefox, Safari exhibits significant lag and choppy animations during scrolling.
Expected Behavior:
The scroll animation should be smooth and fluid, replicating the native behavior observed in Chrome.
Actual Behavior:
Safari displays a laggy and choppy scroll animation when using the Polyfill with the provided demo.
Steps to Reproduce:
Additional Information:
Screen.Recording.2024-09-08.at.15.03.12.1.mp4
The text was updated successfully, but these errors were encountered: