Please free feel to point out if my following understanding is wrong: Assume our display refresh rate is 60hz (I know it is not always the case but let's just assume it is 60hz) so the web page would refresh the screen 60 times every second if everything goes well. That means the rendering is happening at 16 ms interval (roughly) right? So anything in our JavaScript that takes more than 16 ms to execute would cause janky experience to the user. So my question is:
handleScroll
and it is going to take 100ms to execute from start to finish. and we added it to addEventListener('scroll', handleScroll)
. Is it true that whenever scroll
event fires, the user would experience jank experience since 6 frames are skipped/dropped in the rendering cycle? because 100ms / 16ms = 6.25? I know a task takes long time on main thread it will stop all other task until its done, but here I wanted to get some quantitative analysis or methodologies for qualitative analysis for such a performance issue. specifically I wanted to understand (roughly )how many frames are going to get dropped with such a callback (if the refresh rate is 60hz)requestAnimationFrame
tells the browser to run the callback before the next frame is rendered so I saw people mentioned that it can prevent frames being dropped for animation. But it is unclear to me how it is going to help with that since the callback we pass into requestAnimationFrame
is still going to run to completion so if that callback takes more than 16ms we are going to miss the next frame inevitably right?requestAnimationFrame() method tells the browser that you wish to perform an animation and requests that the browser calls a specified function to update an animation before the next repaint. The method takes a callback as an argument to be invoked before the repaint.
Another reason requestAnimationFrame is so useful is the fact that it gives you a time variable which you can use to calculate the amount of time between frames. This is not something that setInterval will do and since setInterval is not 100% accurate it is very possible your animation will get messed up over time.
A macrotask queue is a queue for setTimeout and requestAnimationFrame .
As now you know that the rAF is a Web API, that means the callback will be called asynchronously. Unlike setInterval , requestAnimationFrame does not accept delay argument, instead, it only calls the callback function when the browser is ready to perform the next paint operation.
yes, in that case you would be firing handleScroll
at far less than 60 fps - depending on what your handleScroll
callback is doing, your users may experience some jank.
requestAnimationFrame
will do its best to maintain 60fps, but does not guarantee 60fps. It can potentially run much slower depending on available CPU, GPU, memory, and other limitations.
Note that even when it does run at >60fps, that gives you (as you pointed out) a frame budget of 16-17ms in which to perform your callback actions.
So if your callback takes 100ms to
execute, then you are not going to get a smooth 60fps animation even
using requestAnimationFrame
. Chrome's performance dev
tools
can help you identify what is causing the lag in your animations, but it is up to
you to optimize your callback to run in less than 17ms in order to prevent
dropping frames.
Check out this article for a more in depth breakdown
There are two caveats in your assumptions, first is that you have 16ms budget (on 60 hertz) to spend which is not correct since browser has do some sort of internal calculation to draw next frame which takes quite some time around 6ms on chrome thus we have about ~10ms as explained here
Second assumption is that devices will have 60hz refresh rate, which is going to outdated in near future as more devices using high refresh rates to improve scroll smoothness, or even reducing the refresh rate to save battery; so those are not safe assumptions.
By the way generally the principle is the same, if a task takes long time on main thread it will stop all other task until its done, lets demonstrate it in action:
lag
function simulates a cpu-intesive task that take a while to run; raf
function will move the 200px by scheduling a recursive requestAnimationFrame to itself which will change translateX property of the box; and finally we have a laggyRaf
which uses lag
function to simulate a long task;
const box = document.querySelector('.box');
const x_move_distance = 200;
function lag (delay = 1000) {
const time = Date.now();
while ( Date.now() < time + delay ) {
// waits
}
}
function moveBox ( position ) {
box.style.transform = `translateX(${position}px)`;
}
let counter = 0;
function raf() {
moveBox(counter);
if ( counter < x_move_distance ) {
requestAnimationFrame(raf);
counter++;
}
}
let counter2 = 0;
function laggyRaf() {
moveBox(counter2);
lag(100); //100 ms seconds extra lag
if ( counter2 < x_move_distance ) {
requestAnimationFrame(laggyRaf);
counter2++;
}
}
.box {
width: 100px;
height: 100px;
background: blue;
}
<div class='box'></div>
<button onclick="counter = 0; raf()">start raf animations</button>
<button onclick="lag()">start cpu-intensive task</button>
<br />
<button onclick="counter2 = 0; laggyRaf()">start laggy animations</button>
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With