Javascript性能问题

Question

我正在使用HTML5画布制作游戏引擎，我决定为图像编写一些“包装”，因为这为我提供了各种类型的动画，图像等的通用界面。我的意思是每个对象只有一个.picture属性，可以提供诸如draw()方法，.phi轮换值，.alpha等内容。对我来说这种方法很酷的是基本上，这个.picture属性可以是任何东西：

• 图像（实际上称为Picture的包装器。）
• 动画（许多带有next()和getImage()等功能的图像的包装。）
• 一个合成（许多图像和动画在彼此之上或其他具有绘制方法的东西上绘制。）
• 状态（类似于作文）

为了方便起见，所有这些包装器（图像，动画，合成，状态）都会翻译和旋转上下文（您无法成功旋转HTML5画布上下文而不先将其转换为旋转点）。现在，这是很多翻译！第一个问题：是否正在为每次绘制调用翻译上下文？

另一个问题是这种设计意味着很多函数调用！

以下是该过程的进展情况：

• 渲染器遍历场景，然后遍历场景的图层
• 当它到达drawable（ob.picture != undefined）时，它调用它的.picture的绘制函数（每个可见对象都继承自一个名为Drawable的“类”，该类实际上具有位置和图片属性）

以下是最佳情况：

• drawable的.picture属性是Picture对象（图像包装器）
• .picture将上下文转换为其位置
• .picture旋转上下文
• .picture来电context.drawImage(.picture.image, etc);

这是在最坏情况下发生的事情：

• 图片属性是合成或状态对象
• 构图开始迭代它的元素，每个元素都是另一个图片或动画（或者更糟糕的是，另一个构图/状态）
• 调用他们的绘制方法
• 他们渲染实际图片/遍历他们的元素并重复

如您所见，有很多绘制函数调用。这会是一个显着的速度问题，还是称功能便宜？

编辑：这个问题有所改变。 “游戏”变成了“引擎”，引擎的结构略有改变。但是，没有什么太重要或不同。

Answer 1

不确定上下文翻译，但我认为翻译不是免费的。

对于函数调用，它取决于您绘制的对象数量。函数调用的运行时长度为非零。它虽然很小。

我在下面设置了一个真实的愚蠢而简单的例子来衡量一堆嵌套函数的运行时间：http://jsfiddle.net/luketmillar/D5sHE/

说到图形，每毫秒都很重要。如果你可以避免额外的函数调用，也可以。