如何确定最佳“帧率” （setInterval延迟）在JavaScript动画循环中使用？ [英] How to determine the best "framerate" (setInterval delay) to use in a JavaScript animation loop?
问题描述
编写JavaScript动画时，您当然会使用setInterval（或重复的setTimeout）进行循环。但是在setInterval / setTimeout调用中使用的最佳延迟是什么？
When writing a JavaScript animation, you of course make a loop using setInterval (or repeated setTimeout). But what is the best delay to use in the setInterval/setTimeout call(s)?
在 .animate（）函数的jQuery API页面，用户fbogner说：
In the jQuery API page for the .animate() function, the user "fbogner" says:
如果有人感兴趣：动画是使用setInterval渲染的，时间超过13毫秒。这很快！ Chrome的最快间隔时间约为10毫秒。所有其他浏览器在20-30ms左右采样。
Just if anyone is interested: Animations are "rendered" using a setInterval with a time out of 13ms. This is quite fast! Chrome's fastest possible interval is about 10ms. All other browsers "sample" at about 20-30ms.
知道jQuery如何决定使用这个特定的数字吗？
Any idea how jQuery determined to use this specific number?
开始赏金。我希望有了解Chromium或Firefox背后的源代码的人可以提供一些可能支持特定帧速率决策的硬性事实。或者可能是动画（或框架）列表及其延迟。我相信这为进行一些研究提供了一个有趣的机会。
Started bounty. I'm hoping someone with knowledge of the source code behind Chromium or Firefox can provide some hard facts that might back up the decision of a specific framerate. Or perhaps a list of animations (or frameworks) and their delays. I believe this makes for an interesting opportunity to do a bit of research.
有趣 - 我只是花时间去看看在Google的吃豆人来源，了解他们的所作所为。他们设置了一系列可能的FPS（90,45,30），从第一个开始，然后每帧检查帧的慢度（帧的数量超过其分配的时间）。如果慢度超过50ms 20次，则帧速率下降到列表中的下一个（90 - > 45,45 - > 30）。似乎帧速率从未提升，大概是因为游戏的寿命很短，所以编码就不值得。
Interesting - I just took the time to look at Google's Pac-Man source to see what they did. They set up an array of possible FPSes (90, 45, 30), start at the first one, and then each frame they check the "slowness" of the frame (amount the frame exceeded its allotted time). If the slowness exceeds 50ms 20 times, the framerate is notched down to the next in the list (90 -> 45, 45 -> 30). It appears that the framerate is never raised back up, presumably because the game is so short-lived that it wouldn't be worth the trouble to code that.
哦，并且setInterval延迟当然设置为1000 /帧速率。事实上，他们确实使用了setInterval而不是重复的setTimeouts。
Oh, and the setInterval delay is of course set to 1000 / framerate. They do, in fact, use setInterval and not repeated setTimeouts.
我认为这个动态帧率功能非常整洁！
I think this dynamic framerate feature is pretty neat!
推荐答案
我敢说，相当一部分网络用户正在使用以60Hz刷新的监视器，这意味着每16.66ms就会转换一帧。因此，要使显示器成为瓶颈，您需要生成速度超过16.66ms的帧。
I would venture to say that a substantial fraction of web users are using monitors that refresh at 60Hz, which translates to one frame every 16.66ms. So to make the monitor the bottleneck, you need to produce frames faster than 16.66ms.
有两个原因可以选择13ms这样的值。首先，浏览器需要一点时间来重新绘制屏幕（根据我的经验，从不低于1毫秒）。例如，每隔15毫秒更新一次，这恰好是一个非常有趣的数字 - Windows上的标准计时器分辨率为15毫秒（参见 John Resig的博客文章）。我怀疑在各种各样的浏览器/操作系统上，写得很好的15ms动画看起来非常接近。
There are two reasons you would pick a value like 13ms. First, the browser needs a little bit of time to repaint the screen (in my experience, never less than 1ms). Which puts you at, say, updating every 15ms, which happens to be a very interesting number - the standard timer resolution on Windows is 15ms (see John Resig's blog post). I suspect that an well-written 15ms animation looks very close to the same on a wide variety of browsers/operating systems.
FWIW，fbogner 明显错误关于非Chrome浏览器每隔20-30ms触发setInterval。我写了一个测试来测量setInterval射击的速度，并得到这些数字：
FWIW, fbogner is plain wrong about non-Chrome browsers firing setInterval every 20-30ms. I wrote a test to measure the speed of setInterval firing, and got these numbers:
- Chrome - 4ms
- Firefox 3.5 - 15ms
- IE6 - 15ms
- IE8 - 15ms
- Chrome - 4ms
- Firefox 3.5 - 15ms
- IE6 - 15ms
- IE8 - 15ms
这篇关于如何确定最佳“帧率” （setInterval延迟）在JavaScript动画循环中使用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
