为什么动画帧之间的chromecast需要这么长时间答案

【问题标题】：Why does chromecast take so long between animation frames为什么动画帧之间的chromecast需要这么长时间
【发布时间】：2015-04-15 16:59:33
【问题描述】：

我正在开发一款游戏，它在我的 Mac 上的 chrome 上运行非常流畅，但在我的 chromecast 上运行非常缓慢。我已经对 JS 进行了相当多的优化。

我认为这只是 chromecast 中的低功耗硬件，再加上缓慢的 JS。

但是调查一下，使用 JS 中的性能对象，似乎调用动画帧之间的延迟比我的代码花费的时间长得多。

Court.prototype.update = function () {
if (!window.court.paused) {
    if (window.debug) {
        console.log('time since last update ' + (performance.now() - window.start) + ' ms');
    }
    window.start = performance.now();
    
    window.court.draw(); // my drawing routing
    
    var end = performance.now();
    if (window.debug) {
        console.log('to exit court.draw() took ' + (end - window.start) + ' ms');
    }

    // reschedule next animation update
    window.requestAnimationFrame(window.court.update);
}
};

当我运行该代码并遵循 chromecast 的控制台输出时，我得到以下信息：

自上次更新以来的时间 89.75099999998201 毫秒

court.draw() 耗时 0.984999999665888 毫秒

自上次更新以来的时间 89.35899999960384 毫秒

court.draw() 耗时 29.77499999997235 毫秒

自上次更新以来的时间 106.37199999973382 毫秒

court.draw() 耗时 1.5410000000920263 毫秒

自上次更新以来的时间 93.46499999992375 毫秒

court.draw() 耗时 0.3149999997767736 毫秒

自上次更新以来的时间 91.99499999977706 毫秒

court.draw() 耗时 0.31399999988934724 毫秒

自上次更新以来的时间 126.3730000000578 毫秒

court.draw() 耗时 9.191000000100757 毫秒

自上次更新以来的时间 104.55799999999726 毫秒

court.draw() 耗时 0.3160000001080334 毫秒

自上次更新以来的时间 99.06599999976606 毫秒

court.draw() 耗时 0.3130000000091968 毫秒

自上次更新以来的时间 94.06499999977677 毫秒

court.draw() 耗时 0.3140000003404566 毫秒

自上次更新以来的时间 88.65700000023935 毫秒

因此，我的绘图例程需要 1 到 30 毫秒，但动画帧大约每 100 毫秒调用一次，以提供 10 fps 的最大刷新率。

有没有办法让chromecast降低刷新率？

【问题讨论】：

另一个给你@ali-naddaf stackoverflow.com/users/2765813/ali-naddaf 我想！ :-)

标签： javascript chromecast requestanimationframe

【解决方案1】：

我们已经能够使用 requestAnimationFrame 在 Chromecast 上获得 30FPS。为设备优化代码非常重要。积极重用对象，不要在游戏循环中分配对象或添加新属性。

我建议从没有任何代码的基本 requestAnimationFrame 处理程序开始，以获得基线性能。然后开始添加您的动画逻辑，并使用 Chrome 开发工具来衡量并找到瓶颈。

【讨论】：

谢谢莱昂。然后有些事情......因为数据似乎表明我的 draw() 例程比动画帧周期花费的时间少得多......我计划在 github 上放置一个“chromecast benchmark app/receiver”并存储以允许衡量利率 - 不画任何东西....按照你的建议。谢谢。
我刚刚编写了基准测试接收器/发送器的第一个版本，它在帧之间什么都不做。 github.com/Mackenzie-Serres/benchcast-receiver/tree/gh-pages github.com/Mackenzie-Serres/benchcast（很快将使用 git 子模块进行组合）在我的笔记本电脑 chrome 上，动画帧之间的平均时间为 17 毫秒。在我的 chromecast 上大约是 60 毫秒。
好的，我已经将我的“benchcast”应用程序和接收器上的计算减少到最低限度......是的......它的大部分时间都在大约 60fps（偶尔会下降到 50 秒……并且低至 41fps）……所以看起来我又要优化我的代码了…… :-( 如果人们想玩它，我已经在 PlayStore 中发布了。 play.google.com/store/apps/…，代码在github上github.com/Mackenzie-Serres/benchcast
我们发现了画布性能的回归。我们正在努力在未来的 chromecast 更新中恢复性能。
Leon，我可以下载到我的 Chromecast 的更新中是否有过这项改进？

【解决方案2】：

我现在几乎要放弃了，得出的结论是 Chromecast 很慢，完全停止。

我已经删除了所有的绘图代码，并且有一个只计算几件事的例程，以及对 JS 类上的一些方法的调用，这些方法的作用很小。

定时和帧之间的时间我得到一个三帧的重复周期，帧之间的时间为 10 毫秒、10 毫秒和 30 毫秒 - 平均 50 毫秒 - 或大约 60 fps，这是可以的。

court.draw() 耗时 5.6939999999485735 毫秒自上一帧以来的时间 10.18 毫秒

court.draw() 耗时 5.745999999817286 毫秒自上一帧以来的时间 10.55 毫秒

court.draw() 耗时 5.739999999605061 毫秒自上一帧以来的时间 29.22 毫秒

在我的代码中，每帧只清除和绘制一个代表一个球的非常小的矩形，就会将时间提高到 25 毫秒，而帧之间的时间则为 70 毫秒......这让它慢得难以忍受......

由于没有工具可以进一步了解为什么它如此缓慢，我觉得我现在只是在浪费时间..

【讨论】：

【解决方案3】：

我已经编写了代码来测量主要调用，以及启用/禁用绘图调用（对画布的 context.ClearRect() 和 context.FillRect() 的调用）

结论：

不画画时：

我的代码大约需要 15-16 毫秒（需要改进一下！）帧之间的刷新周期约为 20ms 所以即使不绘制，每帧也会有 4-5ms 的开销......

绘制时：

我的代码大约需要 28 毫秒 --> 调用绘图方法需要额外 12 毫秒帧间刷新周期约为 65ms 所以绘制时每帧有 37ms 的开销 --> 12ms 在我自己的代码中的“前台” ---> 调用 requestAnimationFrame() 之间的“背景”中有 25 毫秒

因此，即使我将自己的代码缩短到 10 毫秒（比如说），我怀疑它是否会将 60 fps 所需的时间缩短到 16 毫秒，因为（大概）后台工作是填充显示器上的像素，没有办法我可以减少更多....我只在绝对必要时删除/绘制东西。

我正在画布上绘制 1、2 或 3 个小框，单色....不确定是否有其他画布绘制技巧可以尝试？

【讨论】：