Wasm-bindgen开发Canvas游戏的调用开销及优化方案问询

你的两个推论都是正确的，这也是目前业界做Canvas类Wasm游戏的通用性能优化准则：

• 首选架构确实是 JS侧负责Canvas绘制调用，Rust/Wasm侧仅运行游戏逻辑：Wasm与JS的跨边界调用存在固定开销，每次wasm-bindgen调用Canvas API都需要完成参数序列化、上下文跳转等操作，单轮开销虽低但高频调用的累计损耗非常可观。把绘制逻辑放在JS侧，Rust侧每帧仅向JS传递一次序列化后的游戏全局绘制状态（比如所有实体的坐标、尺寸、纹理标识、透明度等字段的数组），可以把每帧的跨边界调用次数从数千次压缩到1~2次，额外开销几乎可以忽略。
• 确实应当避免通过wasm-bindgen发起数千次Canvas绘制调用：实测单轮跨边界Canvas调用的开销在几十纳秒量级，每帧如果发起数千次调用，光跨边界损耗就能吃掉几毫秒，很容易击穿60fps要求的16ms单帧预算。如果确实有在Rust侧管控绘制逻辑的需求，可以改用批处理方案：在Wasm内存中先攒好整帧的绘制指令数组，一次性传递给JS侧批量执行，不要单条API单独调用。

如果追求更极致的性能，还可以考虑用WebGL替代2D Canvas，把纹理、顶点这类重数据提前存在GPU侧，Rust侧每帧仅传递更新的全局Uniform变量或者少量变化的顶点数据，跨边界开销还能进一步降低。

内容的提问来源于stack exchange，提问作者Jung Ervin