JavaScript enables high-performance animation and page rendering

No settimeout, no setinterval

If you have to use settimeout or setinterval to animate, the reason is that you need to control the animation precisely. But I think at least at this point in time, the popularity of advanced browsers, even mobile browsers, is enough to give you reason to use more efficient ways to implement animations.

What is efficient

The page is each frame change is drawn by the system (GPU or CPU). But this kind of drawing is different from the PC game drawing, its highest drawing frequency is limited to the display's refresh frequency (not the video card), therefore most cases the highest drawing frequency can only be 60 frames per second (the frame each second, hereafter uses the FPS short name), corresponds to the monitor 60Hz. 60fps is an ideal state, in the daily performance of the page test, 60fps is also an important indicator of the closer the better. In Chrome's debugging tools, there are a number of tools to measure the current frame:

In the next job, we'll use these tools to see the performance of our pages in real time.

60fps is the power and pressure, because it means we only have 16.7 milliseconds (1000/60) to draw each frame. If you use SetTimeout or setinterval (collectively called a timer) to control the drawing, the problem comes.

First, the timer does not have enough precision to calculate the delay. The latency calculation relies on the built-in clock of the browser, and the accuracy of the clock depends on how often the clock is updated (Timer resolution). IE8 and its previous IE version update interval is 15.6 milliseconds. Assuming you set a settimeout delay of 16.7ms, it will update two 15.6 milliseconds before it triggers the delay. This also means delaying the 15.6 x 2-16.7 = 14.5 milliseconds without undue delay.

            16.7ms
DELAY: |------------|

CLOCK: |----------|----------
          | 15.6ms    15.6ms

So even if you set a delay of 0ms to settimeout, it will not trigger immediately. At present, Chrome and ie9+ browser update frequency is 4ms (if you are using a laptop, and in the battery rather than power mode, in order to save resources, the browser will update the frequency of the same system time, which means that the update frequency is lower).

To step back, if the timer resolution can reach 16.7ms, it faces an asynchronous queue problem. Because the callback function in the asynchronous relational settimeout is not executed immediately, it needs to be added to the wait queue. The problem is that if there is a new synchronization script that needs to be executed while waiting for the delay to be triggered, the synchronization script does not line up after the timer's callback, but executes immediately, such as the following code:

function Runforseconds (s) {
    var start = +new Date ();
    while (start + S * 1000 > (+new Date ()) {}
}

document.body.addEventListener ("click", Function () {
    runfors Econds (a);
}, False);

settimeout (function () {
    console.log ("done!");
}, 1000 * 3);

If someone clicks on the body during the 3 seconds of waiting for the trigger delay, will the callback be triggered on time when the 3s completes? Of course not, it will wait 10s, the synchronization function always takes precedence over the asynchronous function:

Wait 3 seconds Delay |    1s    |    2s    |    3s    |--->console.log ("done!");

After 2 seconds     |----1s----|----2s----|          | --->console.log ("done!");

Click the body to

think so: |----1s----|----2s----|----3s----|--->console.log ("done!") --->|------------------10s----------------|

In fact, this is true: |----1s----|----2s----|------------------10s----------------|--->console.log ("done!");

John resign has three articles about Timer performance and accuracy: 1.Accuracy of JavaScript time, 2.Analyzing Timer performance, 3.How JavaScript timers Work 。 From the article you can see the timer in different platform browser and the operating system of some problems.

One more step, assuming that the timer resolution can reach 16.7ms, and assuming that the asynchronous function will not be deferred, the animation using the Timer control is still unsatisfactory. This is the question that the next verse says.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/webkf/script/