为何Canvas 2D Context底层未采用WebGL实现？

这是个非常棒的问题——毕竟你已经亲手用WebGL实现了接近drawImage()的效果，还拿到了性能提升，很自然会疑惑为啥浏览器不直接这么干。我来拆解下几个核心原因：

• 兼容性是Web生态的底线
  Canvas 2D Context比WebGL早诞生好几年，互联网上有海量依赖它精确行为的旧代码。比如像素级的渲染结果、路径绘制的细节、状态栈的管理逻辑，甚至一些微妙的合成模式表现，WebGL要100%复刻这些几乎不可能。一旦浏览器偷偷把底层换成WebGL，很多旧项目可能突然出现渲染bug，这是浏览器厂商绝对不敢冒的风险。

• 简单场景的性能开销反而更高
  WebGL的性能优势体现在批量复杂渲染上，但对于简单操作（比如单次drawImage、画几条线），WebGL的底层开销反而更大：你得创建纹理、绑定缓冲区、设置着色器参数，这些步骤在原生2D引擎里可能就是直接调用GPU的blit操作或者简单图形绘制指令。如果把2D Context底层换成WebGL，简单场景的性能反而会下降，这显然得不偿失。

• 实现与维护的复杂度爆炸
  2D Context的功能远比你想象的多：文本排版（含字体、换行、基线）、复杂路径的抗锯齿、渐变/阴影/滤镜效果、各种全局合成模式、isPointInPath这类碰撞检测……每一项要在WebGL里模拟都要写大量适配代码，还要处理无数边缘情况。浏览器厂商本身已经有成熟的2D渲染引擎（比如Chrome用的Skia），重新用WebGL套一层的开发和维护成本高到离谱，完全不划算。

• 已有硬件加速方案，无需全盘替换
  其实浏览器早就给2D Context做了硬件加速优化——很多时候，复杂的2D操作会被离线渲染成GPU纹理，和WebGL共享GPU资源，但这是在原生2D引擎基础上做的优化，不是直接换成WebGL。这种方式既保留了2D Context的兼容性和易用性，又能在需要的时候拿到硬件加速的性能提升。

总的来说，易用性、兼容性和全场景性能平衡，才是浏览器厂商选择保留原生2D引擎的核心原因——WebGL是很棒的高性能渲染工具，但它的设计目标和2D Context完全不同，强行把后者底层换成前者，反而会丢了2D Context最宝贵的简洁性和兼容性。

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