Chrome不同版本下Canvas2D性能差异求助（Adobe Animate+CreateJS）

• Chrome Canvas底层渲染管线变更：Chrome 110+版本对Canvas2D的绘制批处理、状态管理逻辑做了调整，旧版CreateJS的渲染逻辑（如Stage.update()的重绘区域计算、绘制命令合并）可能与新管线不兼容。可以尝试手动控制重绘范围（使用Stage.update(rect)指定更新区域），减少不必要的全屏重绘。

• CreateJS版本兼容性问题：如果使用的是较老的CreateJS分支（如EaselJS 1.x），可能未适配Chrome 106+的API变化（如OffscreenCanvas的异步处理、ImageBitmap的加载逻辑）。尝试升级到最新稳定版CreateJS，或针对高版本Chrome修改CreateJS核心代码中的渲染逻辑。

• Canvas状态频繁切换的开销：CreateJS生成的代码可能存在大量重复的样式（fillStyle/strokeStyle）、变换矩阵切换操作，新版本Chrome对这类状态切换的性能开销更敏感。可以手动合并相同状态的绘制命令，或使用CreateJS的Graphics.beginBatch()/endBatch()方法批量处理绘制操作。

• GC频繁触发导致的卡顿：新版本Chrome的垃圾回收机制更严格，CreateJS生成的大量临时对象（如每次动画帧创建的Shape、Graphics实例）可能触发高频GC。打开Chrome DevTools的Memory面板，录制内存快照对比106和126版本的内存占用、GC次数，定位未被正确回收的对象并优化。

• 硬件加速实际生效验证：虽然已开启硬件加速，但新版本Chrome对Canvas硬件加速的触发条件更严格（如Canvas尺寸超限、含文本/阴影等特殊绘制操作时会回退到软件渲染）。在地址栏输入chrome://gpu/，查看Canvas项的渲染状态，对比新旧版本是否存在软件渲染的差异。

• 动画调度逻辑适配：Chrome 106+对requestAnimationFrame的调度优先级、后台节流策略做了调整，CreateJS的Ticker类可能未适配新的调度规则。尝试替换为原生requestAnimationFrame手动驱动stage.update()，并确保动画循环在前台时才正常执行。

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