Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

117
Visualizações
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?
about 4 years ago · Juan Pablo Isaza
2 Respostas
Responde à pergunta

0

  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

about 4 years ago · Juan Pablo Isaza Relatório

0

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>

about 4 years ago · Juan Pablo Isaza Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda