Should I use window.webkitRequestAnimationFrame instead of setInterval?

我与影子孤独终老i 提交于 2019-12-06 16:10:58

you can use window.webkitRequestAnimationFrame instead of setInterval

var counter = 0;
var requestAnimationFrame = window.requestAnimationFrame ||
        window.webkitRequestAnimationFrame ||
        window.mozRequestAnimationFrame ||
        window.oRequestAnimationFrame ||
        window.msRequestAnimationFrame;
var cancelAnimationFrame = window.cancelAnimationFrame ||
        window.webkitCancelRequestAnimationFrame || 
        window.webkitCancelAnimationFrame ||
        window.mozCancelRequestAnimationFrame || window.mozCancelAnimationFrame ||
        window.oCancelRequestAnimationFrame || window.oCancelAnimationFrame ||
        window.msCancelRequestAnimationFrame || window.msCancelAnimationFrame;
var animation = function(){
        animationFrame = requestAnimationFrame(animation);
        render();
}
animationFrame = requestAnimationFrame(animation);
function render(){
        counter ++; 
        $('develement').css('-webkit-transform','translate3d(-'+counter+'px, 0, 0)');
}

It depends entirely on what you try to do.

If you need to animate something in "real-time" (as in per frame) requestAnimationFrame is a better choice as it is able to sync to VBLANK of the monitor (via vsync on the gfx card) removing jerks. It's also more efficient and accurate.

setInterval and setTimeout are not able to sync to monitor refresh and are more costly on the system but are better to use if you only need occasional updates or when the delay is more than for example ~70 ms (or about 15 fps).

The requestAnimationFrame is no longer prefixed in Chrome or Firefox (older browsers/versions will need either prefix or a polyfill to work, see for example this one which also gives you more details on this topic). You don't need to specify the window object either.

Yes you should definitely use requestAnimationFrame instead of intervals.

As mentioned before, setInterval only guarantees that a certain function is put onto the JavaScript execution stack after a defined time. However, the real execution can be much later depending on the execution stack at that moment.

The best way (I know) for game animations is using requestAnimationFrame and doing your movement calculations based on the time that has elapsed since the last render and the new one.

mockup code:

function render(){
    var time_passed_since_last_render = Date.now() - window.last_render;
    window.last_render = Date.now()
    // do movements and collision checks here
    // movement distance calculations are based on 'time_passed_since_last_render'
}

while (playerStillAlive) {
    // do things such as checking for input (keyboard push etc.)
    requestAnimationFrame(render);
}
webkitRequestAnimationFrame

It's preferable to the timeout which is windows.setTimeout(fun,millisecond) functions because you're asking the browser to call your function whenever it has available resources, not after a predefined time in milliseconds.

Be aware that scheduling a function in some amount of milliseconds is not a guarantee that it will execute exactly at that time. One reason is that most browsers don't have millisecond resolution time. If you schedule something in 3 milliseconds, it will execute after a minimum of 15 in older IEs and sooner in more modern browsers, but most likely not in 1 millisecond. The other reason is that browsers maintain a queue of what you request them to do. 100 milliseconds timeout means add to the queue after 100 milliseconds. But if the queue is delayed by something slow happening, your function will have to wait and execute after, say, 120 milliseconds.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!