3

我如何判断画布的缓慢性能是由绘图本身引起的，还是由计算应该绘制什么以及在哪里绘制的底层逻辑引起的？

我的问题的第二部分是：如何计算画布 fps？这就是我的做法，对我来说似乎是合乎逻辑的，但我也可能是绝对错误的。这是正确的方法吗？

var fps = 0;  
setInterval(draw, 1000/30);  
setInterval(checkFps, 1000);  

function draw() {  
   //...  
   fps++;  
}  

function checkFps() {  
   $("#fps").html(fps);  
   fps = 0;  
}

编辑： 根据内森的评论，我用以下内容替换了上面的内容： 

var lastTimeStamp = new Date().getTime();  
function draw() {  
    //...  
    var now = new Date().getTime();  
    $("#fps").html(Math.floor(1000/(now - lastTimeStamp)));  
    lastTimeStamp = now;  
}

那么这个怎么样？您也可以仅计算自上次更新以来的毫秒差异，也可以通过这种方式看到性能差异。顺便说一句，我还对两者进行了并排比较，它们通常几乎一起移动（最多相差 2），但是，当性能非常低时，后者的峰值更大。

4

3 回答 3

2

您的 FPS 代码肯定是错误的

setInterval(checkFps, 1000);

没有人保证这个函数会被准确地每秒调用一次（它可能超过 1000 毫秒，或者更少 - 但可能更多），所以

function checkFps() {  
   $("#fps").html(fps);  
   fps = 0;  
}

是错误的（如果此时 fps 为 32，则可能在 1.5 秒内有 32 帧（极端情况））

更好的是查看自上次更新以来经过的实时时间并计算 realtimepassed / 帧数（我确定 javascript 具有获取时间的功能，但我不确定它是否足够准确 = ms 或更好）

fps 顺便说一句不是一个好名字，它包含帧数（自上次更新以来），而不是每秒的帧数，所以帧会是一个更好的名字。

以同样的方式

setInterval(draw, 1000/30);

是错误的，因为您希望获得 30 的 FPS，但是由于 setInterval 不是很准确（并且可能会等待比您说的更长的时间，即使 CPU 能够处理负载，您最终也会得到较低的 FPS )

于 2010-06-20T19:54:04.353 回答
1

检查您是否不使用一些 innerHTML 方法来调试您的项目。这可能会以您无法想象的方式减慢您的项目，特别是如果您执行一些像这样的连接 innerHTML += newDebugValues;

或者像 desau 说的那样，使用 firebug 或 webkit 内部调试器分析您的 cpu 使用情况。

于 2010-10-28T15:54:14.010 回答
1

Webkit 和 Firebug 都提供了分析工具来查看你的 JavaScript 代码中 CPU 周期的使用情况。我建议从那里开始。

对于 FPS 计算，我认为您的代码行不通，但我没有任何好的建议:(

原因是：大多数（全部？）浏览器使用专用线程来运行 javascript，并使用不同的线程来运行 UI 更新。如果 Javascript 线程忙，则不会触发 UI 线程。

因此，您可以运行一些 javascript 循环代码，这些代码将连续“更新” UI 1000 次（例如，设置某些文本的颜色） - 但除非您添加 setTimeout 以允许 UI 线程绘制更改，否则您在 1000 次迭代完成之前不会看到任何变化。

也就是说，我不知道您是否可以在 draw() 例程结束时果断地增加您的 fps 计数器。当然，你的javascript函数已经完成了，但是浏览器真的画了吗？

于 2010-06-20T18:56:56.440 回答