requestAnimationFrame instead of setTimeout about naturalscroll HOT 8 CLOSED

https://www.google.com/search?q=requestAnimationFrame+vs+setTimeout

from naturalscroll.

@asvd if you're open to this I can send a PR

from naturalscroll.

Interesting, but I don't really get what is the point. On my opinion this might make sence, if someone faces performance issues resolved wiht this approach (do you have an example?), or if this would save 10 more bytes out of the library size :-)

from naturalscroll.

The point is that requestAnimationFrame is made for this purpose while setTimeout(fn,1) is most definitely fired more often than once per frame, and perhaps not at the right time to do so, pushing a frame duration long enough to be missed for the next screen update rate.

More info: https://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

The good news since that article is that it doesn't need prefixes anymore so simply swapping out setTimeout(fn,1) for requestAnimationFrame(fn) would be enough for IE10+

Since you probably want this to be supported in more browsers, it's just a few more bytes in #5

If you're interested in saving 14 bytes you could always reopen #4 and pull it in 😄 (and have further size savings if you want to hear them)

from naturalscroll.

I know that requestAnimationFrame is generally better than setTimeout, my point is that there is no serious reason for using it, because it does not solve any issue (there are no known performance issues to be solved). At the same time reusing requestAnimationFrame would require testing it again in many browsers.

If I would write naturalScroll now from scratch, I would use requestAnimationFrame of course, but previously I was not aware of this.

Hopefully, I will find some time soon to review the PR, merge and test it. For this reason I keep this issue open for now. Thanks for the contribution.

from naturalscroll.

After some tests, it appeared that usage of requestAnimationFrame() has lower FPS comparing to setTimeout(). I guess this is because the animation frames frequency is limited by browser at 60 FPS, whereas setTimout() is capable of firing as fast as performace allows.

The CPU usage was also a bit decreased by requestAnimationFrame(), but not that much. In my case, the FPS of setTimeout() was about 120, and CPU usage was about 60% for every of 4 cores. With requestAnimationFrame() the FPS is 60, and CPU is 50% loaded. Maybe this can be explained by the fact that actual heavy redraw frames are more rare than invocations of the callback of setTimeout(). At least I cannot notice the difference with eyes.

from naturalscroll.

requestAnimationFrame is locked to the refresh rate of the screen, which is usually 60FPS. Even if you call something more frequently than that the user won't see any updates because literally the screen won't paint them.

Glad you noticed the lower CPU usage and less frequent calls, that's what RAF offers (while still being as smooth as it can be)

from naturalscroll.

Released in v0.2.2

from naturalscroll.