Significant framerate drop on 6X slowdown in chrome developer tools
antonioberetini opened this issue Β· comments
Issue Summary
Simulating slower CPU 4x and 6x drops framerate to pretty much unusable state
Current Behavior
Framerate on 6x slowdown goes down to 20 fps even when scroll is in stationary position
Expected Behavior
In stationary position framerate should be 60 fps, while in motion some degradation is okay but 10 or 20 fps is not good
Steps to Reproduce
Run the current demo from the website with chrome using 4x and 6x CPU slowdown under performance tab
I am curious about how the simulator works. Actually, I just ran the demo on an iPhone 7 and did not see any framerate drops.
This library was initially developed to improve the scrolling performance on mobile devices in 2015. Since those devices performed well at that time, I do not think the performance will be a big issue as long as the size of the scrollable area is reasonable β do not wrap the whole page into a scrollbar like I did XD.
Love the library I am just trying to be overly cautious before we implement it in or application since we are heavy with animations. I would love to be able to unify scroll behavior across all platforms we are targeting, iOs, Android, Windows and Web.
How did you test this? Is it on Windows or?
How did you test this? Is it on Windows or?
I ran the test on my MacBook Pro 2020 (13-inch, Intel i5-1038NG7) with a 4k display on macOS 12.0.1.
I compared the performance between the API page (native scrollbar) and the demo page (smooth scrollbar). Maybe the API page is too heavy to reach a high scrolling performance, but anyway, our scrollbar is fast enough I think π€£.
On Windows, API page is getting 60 fps
Here is a video demonstrating both with 6x slowdown. FPS is fine but look at the actual rendering. Clearly in smooth scrollbar example visually frames are lost.
2021_12_09_15_52_36.mp4
I think the framerate drops are basically due to the translate3d
that we apply to the scrollbar container. As noted in the caveats:
What's worse, as the scrollable area grows, this plugin will consume a large amount of GPU resources, resulting in jittery scrolling.
The following profilings show that our scrollbar takes twice the time rendering as native scrollbars (both on the demo page), which may result in the framerate drops on modern devices, I guess. Meanwhile, it only takes 1/6 the time in painting compared to the native ones, which will improve the performance on old devices that come with slow repainting.
Native Scrollbar | Smooth Scrollbar |
---|---|
![]() |
![]() |
Since modern browsers have largely improved scrolling performance, I think it is better to use native scrollbars on large pages. (Actually, I am curious why people are still using this plugin π .)
P.S. turning off the scrollbar monitor may slightly improve the performance.
Question, is it possible to enable just the overscroling behavior with native inner scroller?
Of course that's possible, see my old answer on stack overflow: https://stackoverflow.com/a/39616817/2369823
Maybe we can make such a plugin sometime?