Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Confusion about frame drops and requestAnimationFrame

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:

  1. let's say we have a function 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)
  2. I think 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?
like image 664
Joji Avatar asked Sep 06 '21 18:09

Joji


People also ask

What is the aim of the requestAnimationFrame method?

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.

Why is requestAnimationFrame better than setInterval?

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.

Is requestAnimationFrame a Macrotask?

A macrotask queue is a queue for setTimeout and requestAnimationFrame .

Is requestAnimationFrame asynchronous?

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.


Video Answer


2 Answers

  1. 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.

  2. 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

like image 70
D-Money Avatar answered Oct 16 '22 14:10

D-Money


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>
like image 41
Mhmdrz_A Avatar answered Oct 16 '22 13:10

Mhmdrz_A