Inconsistent animation speed depending on monitor refresh rate

[macjuul]

Bug is related to

• [x] embla-carousel (core package)

Embla Carousel version

• v7.0.3

Describe the bug

• The animation speed when navigating via controls or using scrollTo is affected by the refresh rate of your monitor. In my case, carousels will animate more than twice as fast on 144hz monitors compared to 60hz monitors, causing it to either feel to slow or too fast.

CodeSandbox

• Not applicable, this can be tested by manually limiting the refresh rate of your browser on the Embla examples page.

Steps to reproduce

1. View a carousel normally (either with 60Hz or higher)
2. Limit your browser framerate to 30Hz or lower (You can do this in Firefox by setting layout.frame_rate to 30 in about:config)
3. View the same carousel again, you will notice slide animations being twice as slow

Expected behavior

• It is expected that the time it takes for the carousel to travel one snap point is not dependent on the monitors refresh rate as this can cause unintended side effects. I'm using Embla to create a slide animation between multiple forms in a stepper, and to some people the animation feels too slow, while for others it's fine.

Additional context

• This issue is caused by requestAnimationFrame attempting to sync to the monitors refresh rate. This should be fixable by using the time value passed into the callback by requestAnimationFrame (Here's an explanation on StackOverflow)

Thank you for your great library!

[davidjerleke]

Hi @macjuul,

Yep, I actually already have this on my to do so thank you for creating this issue 👍🏻. I’ll let you know when I have something.

Best, David

[robksawyer]

Anyway we could add the ability to adjust the ease type? Using different easings with the autoplay plugin would be a win!

Update: I realized all I needed to do is adjust the timing on the container via css. I'm using tailwind and adding the following class to the inner container div made things much smoother.

.ease-out-quad {
    transition-timing-function: cubic-bezier(0.25, 0.46, 0.45, 0.94);
}

[macjuul]

Hey @davidjerleke, have you had any time to look into this yet? or perhaps an estimate on when this could be tackled?

Thanks!

[davidjerleke]

Hi @macjuul,

Thanks for the follow up. I can’t give proper time estimates because I’m the sole dev on this project with a huge to do list, and I’m maintaining this on my spare time which means a little bit here and there.

But what I can say is that I have it planned for the 7.2.1 release:

• 7.2.0 (to be released soon, currently working on this)
• 7.2.1 <— I have planned it for this release

Best, David

[macjuul]

Great to hear @davidjerleke! Thanks for the heads up, looking forward to a fix. Take your time, no need to hurry 🙂

[davidjerleke]

@macjuul, just wanted to let you know that I will start working on this issue the next time I work on this project. Can’t give an ETA though but I will start looking into it.

[davidjerleke]

Hi @macjuul,

If you want to help out and speed up the process, you could test this CodeSandbox on:

• On a 60 Hz device.
• On a 120 Hz device.

The total runtime for the animation on each device should be something around 1500 milliseconds (give and take 30 milliseconds), no matter the refresh rate.

If that's the case, I have a good starting point and will continue implementing this feature into the Embla Carousel core. Also note that the runtime won't be exactly 1500 and may slightly vary from one try to another (about 30 milliseconds give and take).

Thanks in advance. David

[macjuul]

Hi @macjuul,

If you want to help out and speed up the process, you could test this CodeSandbox on:

• On a 60 Hz device.
• On a 120 Hz device.

The total runtime for the animation on each device should be something around 1500 milliseconds (give and take 30 milliseconds), no matter the refresh rate.

If that's the case, I have a good starting point and will continue implementing this feature into the Embla Carousel core. Also note that the runtime won't be exactly 1500 and may slightly vary from one try to another (about 30 milliseconds give and take).

Thanks in advance. David

This is indeed working perfectly on 144hz, 60hz, and 30hz. Good job!

[davidjerleke]

@macjuul, thanks for taking time and testing it out 👍. I'll let you know when I have a working frame rate agnostic Embla draft.

[davidjerleke]

Hi @macjuul and anyone tracking this issue. I’m done implementing this feature and it will be released with v8.0.0-rc01 pretty soon. I just have to update some examples on the documentation website. Stay tuned.

Best, David

[davidjerleke]

To be released with v8.0.0-rc01.

[davidjerleke]

@macjuul this feature has been released with v8.0.0-rc01.