javascript - 什么会导致 requestAnimationFrame 在高效的 webgl 循环中丢帧？

Question

我一直在编写一个 javascript 演示/测试来学习 WebGL。我有一个相当高效的游戏循环结构(根据 Chrome 开发工具)只需 1-2 毫秒即可运行。我正在使用 requestAnimationFrame 来安排循环的运行(因为这显然是执行 60fps 动画的“正确”方式)。当我查看构建框架的时间轴时，实际的 javascript 代码很少，但框架的“空闲”部分可以将框架推到 30 fps 线上。 FPS 计数器显示 20-40fps，有很多掉落(几乎像锯齿)。

如果我的渲染循环已经是 1-2 毫秒，而它必须适应 16 毫秒才能运行 60fps，还有什么我可以解释的吗？

如果我将循环转换为 setTimeout 循环，它可以轻松保持 60fps。我什至可以在不影响 60fps 的情况下以 Retina 分辨率渲染它。

例如

    // Timeout version
    function gameLoop()
{
setTimeout(gameLoop, 1000/60);
//Process movement, AI, game logic
 renderLoop();
}
function renderLoop()
{
//Drawing all of the 3d stuff
}

对比

function gameLoop()
{
requestAnimationFrame(gameLoop);
//Process movement, AI, game logic
renderLoop()
}
Function renderLoop()
{
//draw objects
}

我也曾在某个时候让 gameLoop 在 setTimeout 上“单独”运行，而 renderLoop 被 requestAnimationFrame 调用。由于他们都在同一个线程上，这似乎有点狡猾，因为他们可能会踩到对方的脚趾。

Answer 1

requestAnimationFrame 实现在不同的浏览器中有所不同，并且由浏览器来维护它的底层行为。

不能保证它会以 60fps 的速度渲染，它只能保证您的函数会在尽可能接近渲染的时刻执行(就在交换缓冲区以将图像数据发送到屏幕之前)。

如果您使用 setTimeout，您可能会得到更频繁的函数调用，但这并没有给您必要的 60fps，因为屏幕可能仍以 30fps 或任何其他速度刷新。在那种情况下，您尝试渲染的频率太高了 - 这会导致 GPU 和能源效率低下(尤其是在移动设备上)。

大多数人以单一频率(相同功能)耦合他们的更新和渲染逻辑。在任何情况下，您都需要使用增量时间修改器更新您的逻辑(速度等)。
这样即使是 30fps，物体移动的速度也是一样的，不管 fps 是多少。