我正在创建一个使用 Canvas API 的简单物理引擎。性能方面的最佳实践是什么？是为 Canvas 中的每个对象(例如每个球、盒子等)创建一个单独的上下文，还是只使用一个上下文？后者涉及为每个要重绘的对象定义上下文中的路径，以及设置颜色等。
当对象数量接近一百时使用多个上下文是个坏主意吗？
我之所以问，是因为我不想在一百个工作小时后得到惊喜，因为我采用了错误的方法。
最佳答案
多 Canvas 的性能提升来自了解您使用多 Canvas 的原因。
除非有用，否则不要使用多个 Canvas :
- Canvas 是适度昂贵的元素。
- 在移动设备上， Canvas 仍然很慢——多个 Canvas 更慢。
以下是使用多个 Canvas 的一些原因:
您有在不同时间动画的绘图。
例如，背景可能每 5 帧动画一次，而更活跃的对象可能每帧动画一次。将背景放在第二个 Canvas 上意味着您不必在每个动画帧都绘制背景。
您想“双缓冲”以提高显示速度。
例如，当当前帧正在显示时，您可能会使用第二个 Canvas 来组装一个复杂的元素，然后使用 displayContext.drawImage(bufferCanvas,0,0) 在显示 Canvas 上绘制缓冲区 Canvas 。这使您可以利用动画帧之间的“停机时间”来准备下一帧。
您使用 Canvas 对单个图像/drawnElement(模板)进行变体。
例如，如果您需要物理屏障(比如灰色建筑的图像)。你可能想要红色、蓝色和绿色的建筑来获得多样性。您可以将灰色建筑图像放在屏幕外的 Canvas 上，并使用上下文的 globalCompositeOperation 将该建筑重新着色为红色、蓝色和绿色的变体。这使您可以通过多种方式重复使用 1 个图像资源。
使用多个 Canvas 还有其他原因，但关键是使用多个 Canvas 来满足需求。
关于javascript - HTML5 Canvas 中的一百个上下文与一个上下文？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18682130/