How to calculate the frame rate FPS of web animations

Standards for smooth animation

First, let’s clarify some concepts. FPS means the number of screen updates per second. The continuous images we usually see are composed of a series of still images. Each image is called a frame. FPS is a physical quantity that describes the speed at which the "frame" changes.

Theoretically, the higher the FPS, the smoother the animation will be. Currently, the screen refresh rate of most devices is 60 times per second, so generally speaking, the animation effect is best when the FPS is 60 frame/s, which means that each frame takes 16.67ms.

Of course, friends who often play FPS games must know that FPS games such as PUBG/CSGO recommend using a monitor with a 144HZ refresh rate. A 144Hz monitor specifically refers to a monitor with a refresh rate of 144Hz per second. Compared with the refresh rate of 60 seconds of ordinary monitors, the picture display is smoother. Therefore, 144Hz monitors are more suitable for first-person shooter games where the viewing angle often maintains high-speed movement.

However, this is only a high refresh rate feature provided by the display. For our Web animation, whether it is supported depends on the browser, and the refresh rate of most browsers is 60 times per second.

Intuitive feeling, experience of different frame rates:

• Animations with a frame rate of 50 to 60 FPS will be quite smooth and comfortable;
• For animations with a frame rate between 30 and 50 FPS, the comfort level varies from person to person due to different sensitivity levels;
• Animations with a frame rate below 30 FPS make people feel obvious lag and discomfort;
• Animations with large frame rate fluctuations will also cause people to feel lag.

OK, so how do we accurately obtain the current FPS value of our page animation?

Method 1: Use Chrome Developer Tools

Chrome provides powerful functions for developers. In the developer tools, we can select the FPS meter option as follows:

Through this button, you can turn on the real-time Frame Rate observation of the page and the GPU usage of the page.

shortcoming:

• This can only observe one or several pages at a time, and requires manual real-time observation
• Data can only be subjective, and there is no very accurate data that is constantly reported or collected.

Therefore, we need a smarter approach.

Method 2: Using the Frame Timing API

Before introducing the following method, let’s continue to popularize some basic knowledge.

Blink kernel early architecture

Take the Chrome browser kernel Blink rendering page as an example. For early Chrome browsers, each page tab corresponds to an independent renderer process, which includes the main thread and the synthesis thread. Early Chrome kernel architecture:

Among them, the main thread is mainly responsible for:

• Javascript calculation and execution
• CSS style calculation
• Layout calculation
• Draw page elements into bitmaps (paint), that is, rasterization (Raster)
• Give the bitmap to the compositing thread

The composition thread is mainly responsible for:

• Upload the bitmap (GraphicsLayer layer) to the GPU as a texture
• Calculate the visible and soon-to-be-visible portion of the page (scrolling)
• CSS Animation
• Tells the GPU to draw the bitmap to the screen

OK, foggy, what is this? In fact, after knowing these two threads, the next concept is to clarify the subtle differences between CSS animation and JS animation (of course they are both web animations).

The subtle differences between JS animation and CSS animation

For JS animations, the frame rate at which they run is the time consumed by the main thread and the synthesis thread combined. For smooth animations, we want each frame to take less than 16.67ms;

As for CSS animation, since its process is not affected by the main thread, it is hoped to obtain the time consumed by the synthesis thread. The drawing frequency of the synthesis thread also reflects the process of scrolling and CSS animation.

The main conclusion drawn from the above is: If we know how long each frame of the main thread and the synthesis thread takes, we can roughly get the frame rate of the corresponding Web animation. So can the Frame Timing API mentioned above help us get this time point?

What is Frame Timing API?

The Frame Timing API is a member of the Web Performance Timing API standard.

Web Performance Timing API is a set of performance API standards launched by W3C to help developers accurately analyze and control the performance of various aspects of a website and improve the performance of a web site.

It contains many subclass APIs to complete different functions, as follows (excerpted from using the performance API to quickly analyze web front-end performance, of course you can also read the original English introduction: Web Performance Timing API):

How to use it? Taking Navigation Timing, Performance Timeline, and Resource Timing as examples, for compatible browsers, they are exposed as read-only properties mounted on window.performance.

Print window.performance in the debugger console and check the timing property:

What do the series of variables in this object represent? They represent every important time point in the entire loading process of our page. You can take a closer look at this picture:

Through this picture and the window.performance.timing above, we can easily count the time consumed by each important node of the page. This is the power of the Web Performance Timing API. If you are interested, you can study it in detail and use it in page statistics.

Frame Timing API Overview

Okay, let’s finally get back to the point. With the help of the Frame Timing API in the Web Performance Timing API, we can easily get the time of the main thread and the synthesis thread in each frame. Or it is easier to directly get the time taken for each frame.

Get the records of the Render main thread and the synthesis thread. The information contained in each record is basically as follows, as shown in the code (refer to Developer feedback needed: Frame Timing API):

var rendererEvents = window.performance.getEntriesByType("renderer");
var compositeThreadEvents = window.performance.getEntriesByType("composite");

Or:

var observer = new PerformanceObserver(function(list) {
    var perfEntries = list.getEntries();
    for (var i = 0; i < perfEntries.length; i++) {
        console.log("frame: ", perfEntries[i]);
    }
});
 
// subscribe to Frame Timing
observer.observe({entryTypes: ['frame']});

Each record contains the following basic information:

{
  sourceFrameNumber: 120,
  startTime: 1342.549374253
  cpuTime: 6.454313323
}

Each record includes a unique Frame Number, Frame start time, and cpuTime. By calculating the startTime of each record, we can calculate the interval between every two frames and determine whether the frame rate of the animation can reach 60 FPS.

but! Take a look at the overall compatibility of the Web Performance Timing API:

Although the Frame Timing API is good, its compatibility is not very friendly at present. Well, to what extent is it unfriendly? There is no browser support yet, it is in the experimental stage, and it is future-oriented programming. Are you kidding me? It's totally useless after talking for so long...

Method 3: Using requestAnimationFrame API

I spent so much time describing the Frame Timing API but in the end it was completely unusable due to compatibility issues. However, this does not mean that such a long description is useless. From the above introduction, we know that if we can get a fixed time point in each frame, then subtracting the two can also approximate the time consumed by one frame.

So, let’s take another approach. This time, we use the requestAnimationFrame API which has good compatibility.

// Syntax window.requestAnimationFrame(callback);

Everyone should be familiar with requestAnimationFrame. The method tells the browser that you want to perform an animation and requests the browser to call a specified function to update the animation before the next redraw.

You apply this method when you are ready to update the screen. This will require your animation function to be executed before the next browser repaint. The number of callbacks is usually 60 times per second, and most browsers usually match the refresh rate recommended by the W3C.

Principle of using requestAnimationFrame to calculate FPS

The principle is that normally the requestAnimationFrame method will be executed 60 times in one second, that is, without dropping frames. Suppose the animation starts at time A, ends at time B, and takes x ms. The requestAnimationFrame is executed n times in total, so the frame rate of this animation is roughly: n / (B - A).

The core code is as follows, which can approximately calculate the page frame rate per second, and we additionally record an allFrameCount to record the number of times rAF is executed, which is used to calculate the frame rate of each animation:

var rAF = function () {
    return (
        window.requestAnimationFrame ||
        window.webkitRequestAnimationFrame ||
        function (callback) {
            window.setTimeout(callback, 1000 / 60);
        }
    );
}();
  
var frame = 0;
var allFrameCount = 0;
var lastTime = Date.now();
var lastFameTime = Date.now();
  
var loop = function () {
    var now = Date.now();
    var fs = (now - lastFameTime);
    var fps = Math.round(1000 / fs);
  
    lastFameTime = now;
    // Do not set to 0, record the difference between this value at the beginning and end of the animation to calculate the FPS
    allFrameCount++;
    frame++;
  
    if (now > 1000 + lastTime) {
        var fps = Math.round((frame * 1000) / (now - lastTime));
        console.log(`${new Date()} FPS within 1S:`, fps);
        frame = 0;
        lastTime = now;
    };
  
    rAF(loop);
}
 
loop();

OK, find a page with animation running continuously for testing, and you can see that the code runs as follows:

Here, I used a page I made before to test it. I used Chrome to call out the FPS meter of the page at the same time and compared the real-time FPS values ​​on both sides. They are basically consistent.

Test page, Solar System. You can paste the above code into the console of this page to test the data:

Comparing the Frame Rate in the upper right corner, the frame rates are basically the same. In most cases, this method gives a good estimate of the frame rate for web animations.

If we need to count the frame rate of a specific animation process, we only need to record the value of allFrameCount at the beginning and end of the animation, and then divide it by the time consumed in the middle to get the FPS value of the specific animation process.

It is worth noting that there is definitely a discrepancy between the result calculated by this method and the actual frame rate, because it regards the time interval between two main thread executions of javascript as one frame, rather than the time consumed by the main thread plus the synthesis thread as one frame as mentioned above. But for the current stage, it is an acceptable method.

The above is the details of how to calculate the FPS of Web animations. For more information on calculating the FPS of Web animations, please pay attention to other related articles on 123WORDPRESS.COM!