preface

Not long ago, apple released the latest iPhone13, in which the Pro model is an unprecedented use of 120Hz ProMotion screen, and claims that the refresh rate can dynamically change between 10 hz and 120 hz to meet specific scene requirements.

Then I thought of the code of animation class abstracted from canvas development before, and I felt deja vu.

High refresh

As we all know, screens have a refresh rate, which is usually 60 hz, which means 60 renderings per second, and the frame rate of the typical video we watch is 30Hz, while the frame rate of the movie system is 24Hz.

Usually, the refresh rate is higher, the human eye in the observed images per second, the more from visual perception would be more fluent, reflected by operating through the screen and more quickly, so, professional electric running hand, especially the FPS player, almost all of them to choose their own display is 144 hz refresh rate go up, Some even have a refresh rate of 240Hz.

Apple’s revolution

So, when a finger touch generates an event on the screen or triggers an animation, the screen immediately runs at a maximum frame rate of 120, which ensures the best user experience. When the user is reading a stationary page, the screen is refreshed at 10 frame rates, which ensures a great user experience and greatly reduces battery consumption due to ineffective redrawing.

To make an extra example, suppose that under normal circumstances, we have a period of 30 frames per second of video as much as 10% of the electricity consumption, in fact in the 60 hz on the screen, every 2 frames are rendering video content is the same, at this point, the dynamic refresh rate, dynamically adjust the frame rate of 30 hz, so roughly, to say the power consumption can be closer to 5%, It’s nearly half of what it was before, but the actual experience is exactly the same as before, and it’s a complete use of everything.

requestAnimationFrame

I don’t know how Apple’s operating system handles dynamic refresh rates at the bottom, but I can say that at least I am fully capable of dynamic refresh in the upper application layer of HTML5.

In HTML5, there is a method called requestAnimationFrame, which belongs to the window object in the browser and is in global scope.

Normally, this method is called, passing in a handle to the method to execute:

function doSomething(timestamp) {
  console.log(timestamp);
}

requestAnimationFrame(doSomething);
Copy the code

It applies a callback that executes the doSomething method when the next frame on the page is refreshed, with the timestamp parameter being the timestamp at which the method was executed.

The output is shown as follows:

If we were to write an animation using this method, we would simply call requestAnimationFrame again in the doSomething method, as shown below:

function doSomething(timestamp) {
  console.log(timestamp);
  requestAnimationFrame(doSomething);
}
Copy the code

The output is shown as follows:

RequestAnimationFrame causes the browser to call back methods on each frame refresh, so it normally calls back at the highest frame rate on the display.

implementation

Some of them are removed, and then write something interesting, which is to achieve a dynamic refresh rate similar to Apple.

Since requestAnimationFrame runs at the highest frame rate, wouldn’t we be limiting the frame rate if we set a premise to execute?

In other words, if we want to dynamically limit the refresh rate to the FPS value, each execution interval should be 1000 / FPS, and only execute our logic if the current time minus the last execution time is greater than this interval, then we have a dynamic refresh rate.

var fps = 2; // Here, I limit the FPS to 2 frames per second
var last = 0; // Last time stamp

function doSomething(timestamp) {
  if (timestamp - last >= 1000 / fps) { // Execute logic when the interval is greater than
    console.log(timestamp); // Execute specific logic here
    last = timestamp; // Record the timestamp to last
  }
  requestAnimationFrame(doSomething);
}

requestAnimationFrame(doSomething);
Copy the code

The output is shown as follows:

The sample

I wrote an example in Canvas that you can try manually if you are interested: CodePen online demo.

  1. When the mouse is outside the interface, I actively limit the refresh rate to10Hz;
  2. The refresh rate changes dynamically when the mouse moves into the interface30Hz;
  3. When the mouse is pressed, the refresh rate dynamically changes to the maximum frame rate.

You can clearly see how smoothly the ball performs the animation.

CodePen online demo

conclusion

In HTML5 canvas animation development, it is not difficult to achieve dynamic refresh rate. Therefore, I also think that since the top application layer can do this, the dynamic refresh rate technology of iOS bottom layer should not be only available to iPhone13 Pro series in theory, because it has nothing to do with the quality of the screen. Rather, it restricts at the software level when event callbacks should occur.

So it’s reasonable to expect apple to apply this technology to its entire product line in the future.

Welcome criticism and correction!