Skip to content

feat: extra performance and stabilization options for autoscroll #14

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

dmitriynazaratiy
Copy link

Related Issues

#10

Description

This PR introduces new set of performance and stabilization related options for an AutoScroll:

  • fpsLock number (optional) - when fpsLock is set AutoScroll renders will perform as if device has real fps value equal to it. This includes skips render for frames if real fps is higher and proper calculation for an expected render position if real fps is lower than fpsLock value. This option solves an issue of different frame rates on different devices as well as known problem of requestAnimationFrame() potential skipping animation frames.
  • virtualSpeed boolean (optional) - when virtualSpeed flag is set to true AutoScroll will perform animation as if slider component has its size equal to virtualViewportSize regardless of real slider size. This also includes scaling of a speed value up or down during position calculations to stabilize animation speed across different screen sizes. virtualSpeed and virtualViewportSize options pair solves an issue of original algo being bound to a px per frame resulting in a different slide per frame speed on different screen sizes or different slider size (which created an illusion of different scroll speed)
  • virtualViewportSize number (optional, default = 1000) - when virtualSpeed flag is set to true this option value is used to determine virtual size of a slider component for further calculations (see virtualSpeed option description)

Example of usage

https://codepen.io/d-nazaratiy/pen/dywywyq

@Piteriuz
Copy link

Piteriuz commented Jul 22, 2024

Thank you very much, the site works much faster now. @NaotoshiFujita could you please merge this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants