javascript - RequestAnimationFrame定期加快/降低速度

Question

据我了解，requestAnimationFrame的运行速度应尽可能接近浏览器的帧速率(约60fps)。为了确保确实发生这种情况，我一直在记录每个requestAnimationFrame调用的时间戳，如下所示:

function animate(now){
    console.log(now);
    window.requestAnimationFrame(animate);
}
window.requestAnimationFrame(animate);

Console.log数据显示，调用始终相距约0.016674毫秒，因此表明帧速率约为≈60fps(准确地说是59.9736116108912fps)。

Console.logs(示例数据):

Timestamp   FPS               (Current - previous) timestamp
------------------------------------------------------------
100.226     59.97361161       0.016674
116.9       59.97361161       0.016674
133.574     59.97361161       0.016674
   .             .               .
   .             .               .
150.248     59.97361161       0.016674
166.922     59.97361161       0.016674
183.596     59.97361161       0.016674
200.27      59.97361161       0.016674

到目前为止，requestAnimationFrame调用是在一致的时间间隔内进行的，并且没有任何调用滞后/执行得太快。

但是，修改animate()函数的内容以执行相对复杂的函数会导致requestAnimationFrame调用不一致。

Console.logs(示例数据):

Timestamp       FPS               (Current - previous) timestamp
------------------------------------------------------------
7042.73         59.97361161       0.016674
7066.278        42.4664515        0.023548
7082.952        59.97361161       0.016674
7099.626        59.97361161       0.016674
   .                 .                .
   .                 .                .
17104.026       59.97361161       0.016674
17112.84        113.4558657       0.008814
17129.514       59.97361161       0.016674
17146.188       59.97361161       0.016674

从上面的数据样本中可以看出，时间戳差异和帧速率不再稳定，有时发生得太早/太晚，导致帧速率不一致。如果requestAnimationFrame一直被延迟调用，我会假设由于JavaScript的单线程性质，驻留在animate()函数中的复杂代码执行所需的时间太长，从而导致requestAnimationFrame调用延迟。但是，由于requestAnimationFrame偶尔被调用为时过早，因此似乎并非如此。

我的代码(骨架):

for (var counter = 0; counter < elements.length; counter ++) //10 elements
{
  //some other code

  animate(element);
}

function animate(element)
{
   // function invocation => performs some complex calculations and animates the element passed in as a parameter

   window.requestAnimationFrame(function() { animate(element) } );
}

从上面的代码片段可以看出，在初始for循环内，每个元素的requestAnimationFrame被多次调用。还希望对每个元素无限地进行RequestAnimationFrame调用。由于要执行的动画是 且时间紧迫的(动画时序在这种情况下非常重要，应尽可能准确)，因此至关重要的是，requestAnimationFrame调用始终以一致的时间间隔进行。理想情况下，这些时间间隔应尽可能接近0.016674(≈60fps)。

(在每个 Canvas 元素上)与要执行的动画有关的一些详细信息:

我有一个非常特殊的情况，要求我在时间上尽可能准确地绘制眨眼/闪烁的动画，即在指定的时间间隔内， Canvas 颜色必须以一致的速率进行更改。因此，例如， Canvas 颜色需要精确地保持红色0.025秒，然后将 Canvas 颜色设置为蓝色时再保持0.025秒，然后再将 Canvas 红色设置为0.025秒，以此类推...(动画应对于每个元素，都可以无限地进行下去)。我当前的方法涉及跟踪动画循环本身中经过的帧数(因此，每个requestAnimationFrame调用都对应一个帧)。

由于在60Hz监视器上无法达到0.025秒的准确帧长，因此每个“红色/蓝色” Canvas 周期都应“近似”。因此，考虑使用60Hz监视器，创建一个完整的周期，其中 Canvas 最初是红色，然后是蓝色，则总共需要3帧(1秒/60 = 0.01666667秒* 3帧= 0.05秒=>一个完整的红色/蓝色循环所需的持续时间)。将0.05秒除以2将得到所需的帧长(即0.025秒)，但是由于无法在60Hz显示器上实现，因此可以通过显示2个红色 Canvas 帧，然后是单个蓝色帧(由此形成整个3帧周期)。不幸的是，即使考虑到监视器的刷新率，定时也往往会波动，从而导致不希望的误差。

最后的问题:

您能否弄清楚是什么导致了这种不一致的requestAnimationFrame行为？

是否可以应用任何优化来确保requestAnimationFrame调用以一致的时间间隔执行？

如果我使用其他某种功能(例如，将web worker与setInterval()函数结合使用)，是否可以实现更好的计时精度？

Answer 1

requestAnimationFrame将“竭尽所能”以“一致”的帧速率运行。那不能保证60fps。它只是说它将尽快动画。

简而言之，该方法使您可以在下一个可用的屏幕重绘上执行代码，从而避免了与用户浏览器同步和硬件准备就绪以进行屏幕更改的猜测工作。

我们输入一个包含要运行的代码的回调函数，当屏幕准备好接受下一个屏幕重绘时，requestAnimationFrame()将运行它。

为了使动画保持恒定，您必须根据实际增量计算回调重新计算值中的数据，而不假定恒定的FPS。

例如:

function moveit(timestamp, el, dist, duration){
 //if browser doesn't support requestAnimationFrame, generate our own timestamp using Date:
 var timestamp = timestamp || new Date().getTime()
 var runtime = timestamp - starttime
 var progress = runtime / duration
 progress = Math.min(progress, 1)
 el.style.left = (dist * progress).toFixed(2) + 'px'
 if (runtime < duration){ // if duration not met yet
 requestAnimationFrame(function(timestamp){ // call requestAnimationFrame again with parameters
 moveit(timestamp, el, dist, duration)
 })
 }
}

requestAnimationFrame(function(timestamp){
 starttime = timestamp || new Date().getTime() //if browser doesn't support requestAnimationFrame, generate our own timestamp using Date
 moveit(timestamp, adiv, 400, 2000) // 400px over 1 second
})