我正在使用 HTML5 画布制作游戏引擎，我决定为图像编写一些“包装器”，因为这为我提供了一个用于各种类型的动画、图像等的通用界面。我的意思是每个对象都有一个.picture属性，它提供draw()方法、.phi旋转值、an.alpha等。这种方法对我来说很酷的是，本质上，这个.picture属性可以是任何东西：
Picture图像（实际上称为包装器）。- 动画（许多图像的包装器，具有一些功能，例如
next()和getImage()）。 - 合成（许多图像和动画被绘制在彼此之上或其他具有绘制方法的东西上。）
- 一个状态（类似于组合）
为了方便起见，所有这些包装器（图像、动画、合成、状态）都会翻译和旋转上下文（如果不先将 HTML5 画布上下文翻译到旋转点，就无法成功旋转 HTML5 画布上下文）。现在，有很多翻译！第一个问题：为每个绘制调用翻译上下文是否昂贵？
另一个问题是这种设计意味着很多函数调用！
流程如下：
- 渲染器遍历场景，然后是场景的图层
- 当它到达一个drawable（
ob.picture != undefined）时，它调用它的.picturedraw函数（每个可见对象都继承自一个名为Drawable的“类”，该类实际上具有位置和图片属性）
以下是在最佳情况下发生的情况：
- drawable 的
.picture属性是一个 Picture 对象（图像的包装器） - 将
.picture上下文转换为它的位置 - 旋转
.picture上下文 .picture来电_context.drawImage(.picture.image, etc);
这是最坏情况下发生的情况：
- 图片属性是一个合成或状态对象
- 合成开始迭代它的元素，每个元素都是另一个图片或动画（或者，更糟糕的是，另一个合成/状态）
- 调用他们的绘制方法
- 他们通过他们的元素渲染实际图片/迭代并重复
如您所见，有很多绘图函数调用。这会是一个重大的速度问题，还是调用函数很便宜？
编辑：这个问题发生了一些变化。“游戏”变成了“引擎”，引擎的结构略有改变。但是，没有什么太重要或不同。