In this tutorial I will explain everything about requestAnimationFrame() function. This function was introduced by Robert O’Callahan, a hacker at Mozilla.
Browsers are single threaded, that means each website is fetched and displayed using a single thread. Downloading, Parsing, DOM creation, CSSDOM creation, Render tree creation, Layout(or reflow) and Paint(or repaint) is done using a single thread.
This main thread also maintains a queue which has asynchronous code enqueued to be executed one by one. This enqueued code can be of async ajax, event handlers, timers code, image loading etc. New items(pieces of codes) are added to this queue as async code are registered(ajax, timers etc) or async events occur(click event, key event, html image element etc). One long running queue item can stop the execution of other queue items. This thread dequeues this queue whenever possible. We can stop execution(remove) of an enqueued item.
setInterval() and setTimeout() are used to execute a function after a certain interval of time asynchronously. The main thread enqueues the function in the queue after the specified interval of time(or delay) and therefore it is executed when its turn comes. Ofcourse the function is not executed exactly at the delay specified because of other items in the queue waiting to be executed.
A simple example of setInterval()
A simple example of setTimeout()
But now developers are using requestAnimationFrame to create animations. requestAnimationFrame also fires a callback regularly to create fps but the delay is not specified by the user, its decided by the browser. Let’s compare the both the of creating animations.
Comparison between requestAnimationFrame and setInterval/setTimeout
1. Using timers we have to guess the delay for animation(to achieve fps), this is very tough to guess because we don’t know the kind of device user is using. But when using requestAnimationFrame we don’t have to make any guesses. The fps is decided by the display refresh rate(60 Hz is 60 fps) and computer computation power.
2. Timers callback rate is same even if the browser is running in background state. But requestAnimationFrame slows down the rate when browser is in backgroundState. This helps to reduce power consumption and prevents computer from heating.
3. When we using requestAnimationFrame the browser knows that we are creating animations there it can optimize concurrent animations together into a single reflow and repaint cycle, leading to higher fidelity animation. It can prevent unnecessary reflows and repaints.
4. Using timers there is chances that we may assume a refresh rate(or fps) higher than the the system refresh rate, in that case many frames are dropped. This is called frames dropping. If a computer has 60 hertz refresh rate then the timer delay should be 1000/60. If it is lower than that then frames are dropped. But requestAnimationFrame prevents frame dropping because knows the refresh rate.
5. When timer callbacks take more time than the assumed delay, it starts adding more callbacks to the queue which causes the browser to stall and application stops responding. requestAnimationFrame prevents this issue also.
Animation using requestAnimationFrame()
Let’s create a simple animation using requestAnimationFrame
Polyfill for old browser
Old browsers don’t support requestAnimationFrame therefore use can use rAF.js
I tried to cover everything that was required to understand requestAnimationFrame. I will be adding more notes to this post as I will come through. Thanks for reading and please like and share this article.