Requestanimationframe implementation: recursive / recursive fps limited / one-off

I've studied requestanimationframe documentation and looked for many posts about the usage of it, but i still haven't get a clear answer on one of my thought.

I understand that requestanimationframe is scheduling a task to be executed right at the beginning of the next frame, so the code that does dom manipulations will have a better chance to be finished and painted before the pain cyle. (unless setInterval or setTimeout which usually executes a lot later, causing the well known 'running out of time before the frame gets painted' => dropping frames).

1. The recursive way

The simplest example to use requestanimation frame is the following:

function animate() {
  requestAnimationFrame(animate);

  // drawing code comes here
}
requestAnimationFrame(animate);

This will give you a smooth animation if you have something that needs to be updated frequently, and also giving you the benefit of not dropping any frames during your animations. This will usually gives you 60fps animations, but if your browser and screen supports 144hz/fps, then you can easily end up having 144fps animations (6.95 ms cycle).

2. Fps limited animations

Other examples also introduce ways to limit the fps to a certain number. The following code snippnet shows how to limit your fps to 30 fps:

const fpsInterval = 1000 / 30;
let previousTime = 0;
function animate(time) {
  requestAnimationFrame(animate);

  const deltaTime = time - previousTime;

  if (deltaTime > fpsInterval) {
    // Get ready for next frame by setting then=now, but also adjust for your
    // specified fpsInterval not being a multiple of RAF's interval (16.7ms)
    previousTime = time - (deltaTime % fpsInterval);
  }

  // drawing code comes here
}
requestAnimationFrame(animate);

3. One-off animations

I've been wondering a third case, when you just want your animation to be scheduled precisely, even if you have 1 or just a few amount of updates in each second. A best example is when you have a websocket connection and each update will introduce a dom manipulation, but the update rate is far too low to do it in a recursive way.

// setting up websocket connection

ws.onmessage = (data) => {
  // changing application state
  myApplicationState = JSON.parse(data);

  requestAnimationFrame(animate);
}

function animate () {
    // drawing code comes here
}

Now here is my question for you all:

Does this make sense to call requestanimationframe right from the callback of a websocket onmessage function, or should i be using the recursive way?

So far I haven't tested it (in progress), but i have a feeling it does still going to give you the benefit of well-timed animations that can be executed without dropping a frame.

My real-life example is similar, i only have 5 messages in a second and i'd like to call requestanimationframe ONLY 5 times in a second.

My thought of doing this vs the recursive way:

• Using requestanimation frame in a recursive way will incredibly increase the script execution time when measured in chrome profiling tools.
• Only calling requestanimationframe when a websocket comes will still make sure to have the benefit of the feature, yet not polluting the callstack and reducing execution time

My initial measures were the following. I've spin up chrome profiling and run it for 10 seconds and measured the script execution times (we're not measuring render or paint since they are basically identical):

Script execution times:

• 1. recursive way: 4500ms
• 2. fps limited way: 4300ms
• 3. one-off animated way: 1700ms

While recursive requestanimationframe solution is giving you a super smooth and good user experience, it's also very costy for your CPU and execution times. If you have multiple components doing animations with recursive requestanimationframe, you're going to hit a CPU bottleneck pretty soon.

Oddly this last case causing some fps drops, which I do not understand. My understanding is that you can call requestanimationframe whenever you want and it'll only execute the begginning of the next frame. But it seems there is something i dont know about.

Here is a picture of what is happening. I still don't understand it. requestanimationframe function was called before the end of the frame, but somehow because it was part of a bigger function call, it's marked as 'dropped' in chrome. Wonder if that's just a bug in the chrome profiling or was it for real dropped.

I wonder what you guys thinking about this topic. I'll update this post with some chrome performance metrics soon.