前言
在过去的十年中，Web图形接口经历了三次重大技术迭代：2011年的WebGL、2017年的WebGL 2.0以及2023年正式落地的WebGPU。这三个技术阶段不仅反映了硬件能力的提升，更揭示了Web图形开发从"适配"到"掌控"的思维转变。本文将基于技术演进脉络，主要谈谈各阶段的核心特性、突破性价值以及自身的固有局限。
模型架构横空出世的WebGL 1.0
2006 年的时候，一个叫做 Vladimir Vukićević的美籍塞尔维亚工程师，在即将到来的 HTML 的 Canvas 标签上做了一个个人项目，用 Canvas 标签实现了 OpenGL 的原型，他把这个项目叫做 Canvas3D。这个项目被他的雇主 Mozilla 和很多其他浏览器厂商注意到了，被认为很有前途，于是他们就开始继续往下做这件事情，于是就有了 WebGL。就在 2011 年的时候，WebGL 1.0 标准被正式推出。
WebGL，由Khronos Group主导开发，基于OpenGL ES 2.0标准。它的诞生标志着网页端3D图形渲染无需插件的开端，首次让开发者通过JavaScript和GLSL着色器语言直接在浏览器中实现硬件加速的图形渲染。这一技术极大地推动了在线游戏、数据可视化、教育工具等领域的创新。
但受限于OpenGL ES 2.0的架构，WebGL 1.0仅支持固定渲染管线，缺乏现代图形API的灵活性。例如，开发者无法直接管理GPU内存资源，也不支持计算着色器，复杂场景的性能优化成为难题，尤其在移动端设备上容易遇到性能瓶颈。此外，WebGL对多线程的支持不足，主线程的JavaScript逻辑与渲染任务容易互相阻塞，导致卡顿问题频发。
WebGL的渲染管线，来源：CS逍遥剑仙
姗姗来迟的WebGL 2.0
时间来到2013年11月，Khronos组织高调宣布WebGL 2.0草案，承诺将带来
OpenGL ES 3.0的全新特性。彼时iPhone 5s搭载的A7芯片已支持Metal API，NVIDIA的Maxwell架构显卡正在横扫游戏市场。所有人都以为这是浏览器图形技术的飞跃起点，却未料到这竟是一场长达四年的技术马拉松。WebGL 2.0标准推出后，Google 和 Mozilla 这两家浏览器厂商都同步支持了，但是作为Web图形最重要的玩家之一——苹果，却缺席了这个标准。
自2014年推出Metal API后，苹果便将OpenGL标记为“遗留技术”，其驱动程序维护团队早已转向新战场。这种战略转向导致Safari团队不得不反向移植Metal特性到OpenGL接口，犹如在废弃铁轨上强行驾驶高铁。更棘手的是移动端GPU碎片化：当Adreno 330（2014年主流移动GPU）的驱动无法稳定支持Transform Feedback时，标准制定者不得不在性能和兼容性之间反复妥协，最终导致核心特性在移动浏览器形同虚设。
事实上，苹果一直到2021年9月份才支持WebGL2.0。主流浏览器对WebGL标准升级的支持跨越了接近10年周期，在发展日新月异的Web领域，10年时间，可以说是错失了WebGL发展的黄金时期。
苹果早期大力支持的基于OpenGL ES开发的游戏，图片为水果忍者
然而，放眼当下市场上的移动设备中，已有高达 97% 的机型已支持 WebGL 2.0。这意味着，web端图形引擎经过技术升级后可以充分利用 WebGL2 带来的性能优化，如更高效的渲染管线、更低的 CPU 开销以及更丰富的视觉效果，从而显著提升互动体验和运行效率。
相比于WebGL1.0，WebGL2.0的底层基于GLSL ES3.0的版本，支持3D纹理、2D纹理数组，提高了web端的可视化效果上限。除此以外，多重渲染目标、VAO、UBO的直接支持大大提高了Web端的图形渲染性能。
早在2023年末，我们Mapmost SDK 就进行了底层的技术升级，全面接入WebGL2.0标准，使地图引擎整个技术栈更契合当前硬件发展趋势，为更复杂、更高质量的渲染需求提供更强大的支持。
免费试用地址：www.mapmost.com/#/layout/we…
下面简单介绍下WebGL 2.0的几个重点特性
#多重渲染目标（MRT）
WebGL 2.0 的多重渲染目标（MRT）支持在单次渲染中将片元着色器的数据同时输出到多个颜色附件（如纹理），其核心应用是延迟渲染（Deferred Shading）：通过 MRT 将几何信息（颜色、法线、位置、材质等）分别写入多个纹理组成的 G-Buffer（几何缓冲区），后续光照计算仅需基于屏幕像素遍历 G-Buffer 数据，避免重复绘制几何体，大幅优化复杂场景性能，尤其适用于多光源、动态光照的游戏和3D应用场景。
WebGL2.0 多重渲染目标（MRT）
#3D纹理
WebGL2.0的3D纹理（如**sampler3D**）通过三维坐标采样体数据，可高效映射体元栅格（体素网格），将密度、颜色等属性编码为纹理层级，支持GPU加速的体积渲染；在云雾仿真中，3D纹理可参数化动态密度场，结合光线步进算法计算光线在体素内的散射与吸收，实现半透明渐变与光照交互效果，兼顾实时性与物理可信度。
基于3D纹理实现体元栅格表达的日照率
基于3D纹理实现的体积云效果
#Uniform Buffer Object（UBO）
WebGL2.0的UBO（Uniform Buffer Object）技术通过将多个Uniform变量（如光照强度、材质属性等）封装为结构化数据块并绑定至显存缓冲区，实现多着色器程序间的参数高效复用与批量更新；在PBR材质渲染中，UBO可集中管理复杂的光照模型参数（如环境光遮蔽、金属度/粗糙度）及场景光源属性（如方向光、点光源矩阵），通过单次数据提交支持大规模物体渲染，显著降低CPU-GPU通信开销，保障高精度材质与动态光照的实时一致性。
Mapmost中底层基于UBO管理的PBR材质渲染效果，来源：Mapmost
借助 WebGL2，我们可以利用更高级的着色器功能、更高效的缓冲区管理以及多目标渲染等特性，使渲染流程更加流畅，提升整体视觉效果和交互体验。这对于需要高性能图形计算的 Web 应用而言，无疑是一次重要的技术飞跃。
#WebGL的自身局限
然而，即便是WebGL2.0，底层仍然是基于OpenGL ES标准。OpenGL ES本身是一个非常古老的标准，OpenGL ES 的设计理念可以追溯到 1992 年，WebGL 到现在还在使用这些理念。而这些理念其实已经非常不符合今天的 GPU 的工作原理了，浏览器开发者为了实现WebGL，需要付出极大成本。其次，WebGL的API设计较为复杂，需要开发者具备一定的图形编程基础。此外，WebGL主要关注图形渲染，对于计算密集型任务的支持相对较弱。
WebGPU：Web图形的未来之星？
正是因为WebGL的局限性，才有了WebGPU的诞生，WebGPU不是继承自WebGL，而是一个全新的提案。这个提案最初源自于Google在2016年提出WebGL Next，Google当时已经发现了WebGL存在的一些问题了，新的提案期望做一个精确的图形 API。
WebGPU发展时间线，来源：公众号：MoonWebTeam
WebGL 基于 OpenGL ES，而 WebGPU 更像是一个“浏览器中的 Vulkan”。核心差异：
1️⃣底层架构
- WebGL：抽象了 GPU 细节，开发者无需关心底层实现，但灵活性受限。
- WebGPU：暴露现代 GPU 特性（如多线程、计算管线），允许更细粒度的控制。
2️⃣性能潜力
- WebGL：单线程渲染、全局状态机模型，容易成为性能瓶颈。
- WebGPU：支持多线程提交指令（Command Buffer）、显式资源管理，最大化 GPU 利用率。
3️⃣功能扩展
- WebGPU 支持计算着色器（Compute Shader），可直接运行通用计算任务（如物理模拟、AI推理），而 WebGL 仅限图形渲染。
- 更现代的渲染特性：例如 Mesh Shading、光线追踪（未来支持），为复杂场景铺路。
目前主流 Web 端引擎对 WebGPU 的支持正在逐步推进中。Babylon.js 为例，其从 v5.0 开始实验性支持 WebGPU，目前已能在最新版本中实现完整的渲染管线（如 PBR、计算着色器），并针对性能优化做了深度适配，成为生态内最成熟的 WebGPU 方案之一。
有国外技术博主针对 Babylon.js 的 WebGL 与 WebGPU 渲染性能进行了同场景对比测试，结果令人震撼：WebGPU 帧数直接飙升50帧，而 CPU 耗时更是从 63ms 断崖式下降至 0.2ms！这一数据不仅验证了 WebGPU 在现代 GPU 并行计算与显式控制权上的碾压级优势，更揭示了其彻底释放硬件潜能的能力——通过减少驱动层开销、多线程协同与 GPU 资源精准调度，WebGPU 真正实现了从“勉强够用”到“桌面级性能”的质变。
Babylon.js 的 WebGL 与 WebGPU 渲染性能对比，来源：youtube
🌟最后谈谈个人的理解
#WebGPU 真的更快吗？
WebGPU 的性能优势是毋庸置疑的，但它并非“万能加速器”。
性能提升的幅度高度依赖场景：在需要大规模并行计算（比如实时物理模拟、AI 推理）或复杂渲染管线（如动态光影、高精度模型）的场景下，WebGPU 通过多线程指令提交、显式资源管理、计算着色器等特性，可以轻松实现数倍于 WebGL 的帧率。
然而，这些优化需要开发者深入理解现代 GPU 架构，甚至像写 Vulkan 一样手动管理内存和管线状态——这意味着更高的开发成本和门槛。如果只是渲染一个简单的 3D 模型，WebGPU 的复杂性与 WebGL 的便捷性相比，反而可能得不偿失。
另一方面，优化也需要看**使用场景。**在实际应用场景中，通过使用WebGPU 的多线程指令提交获取的性能提升有多少？有没有一种可能，即便是有上万个drawcall，我们依然不能获取到数倍的性能提升，甚至性能上几乎没有变化？
当GPU计算成为瓶颈时（如大规模点云渲染），无论使用Three.js框架或原生WebGL/WebGPU，帧率提升均有限，此时应该聚焦着色器优化、剔除策略等渲染管线优化；若CPU负载较高（如复杂矩阵计算或高频交互场景），WebGPU则可以通过减少框架抽象层开销，来显著降低CPU耗时，虽帧率未必提升，却能增强交互响应流畅度。WebGPU的核心价值在于计算着色器与显存管理，适合神经渲染等新兴场景，而非盲目替换现有方案。
#WebGPU 会取代 WebGL 吗？
我的观点是：短期内不可能，但长期会共存。
WebGL 的生态已经非常成熟，Three.js、Babylon.js 等库覆盖了大量轻量级需求，且学习曲线平缓，适合快速开发。而 WebGPU 更像是一个“专业级工具”，目标用户是追求极致性能的团队（如开发浏览器端 3A 游戏、工业级仿真），或是需要通用计算（GPGPU）的场景（如 Web 版 Stable Diffusion）。未来，随着 WebGPU 生态的完善和高级框架（如 three.js 的 WebGPU 后端）的成熟，它可能会逐渐渗透到主流开发中，但 WebGL 仍会在简单应用场景中占据一席之地。
总结来说：WebGPU 是 Web 图形的一次革命，它让浏览器首次具备了与原生应用抗衡的图形和计算能力。但它的价值并非“取代谁”，而是拓宽了 Web 的可能性——从元宇宙到实时协作，从端侧 AI 到科学可视化，这些需要榨干 GPU 每一分性能的领域，才是 WebGPU 真正的舞台。至于性能提升是否“肉眼可见”，答案很简单：“看场景，但潜力巨大”。
WebGPU 不是万能的“金钥匙”🔑，但它是 Web 图形迈向“桌面级性能”的里程碑。🚀
你对 WebGPU 怎么看？欢迎加入交流群讨论！👇
关注 Mapmost，持续更新 GIS、三维美术、计算机技术干货
Mapmost 是一套以三维地图和时空计算为特色的数字孪生底座平台，包含了空间数据管理工具（Studio）、应用开发工具（SDK）、应用创作工具（Alpha）。平台能力已覆盖城市时空数据的集成、多源数据资源的发布管理，以及数字孪生应用开发工具链，满足企业开发者用户快速搭建数字孪生场景的切实需求，助力实现行业领先。
欢迎进入官网体验使用：Mapmost——让人与机器联合创作成为新常态
