从 Flash 到 WEBGPU，Web 图形技经历过的变革你了解吗？

作者 | ASHLEY

译者 | 弯月，责编 | 夕颜

出品 | CSDN（ID:CSDNnews）

近年来，图形技术（包括Web上的图形技术）已经发生了翻天覆地的变化，随着WebGPU的出现，Web正处于下一次重大变革的风口浪尖上。在本文中，我将简要介绍图像API的发展历史以及未来的走向。我还将重点介绍Construct——这项引领Web游戏引擎的尖端技术，以及该技术这些年来的发展历程。

 

有关术语的几点说明

 

Construct的渲染器指的是将所有图形绘制到屏幕上的代码，也称为渲染。说起渲染技术，大多数现代设备都包含两个芯片：

 

• CPU（*处理单元），运行主要应用程序逻辑的通用芯片。

• GPU（图形处理单元），专门用于快速处理图像渲染的芯片。

 

一般来讲，CPU上的应用程序逻辑都会构建一个渲染指令列表，然后将这些指令发送到GPU上快速执行，因此两者都与渲染有关。如今，GPU还有其他方面的专业用途，例如AI。从广义上讲，CPU的设计是为了有效地运行串行指令（一个接一个地运行指令），这是应用程序代码所特有的，而GPU的目标是有效地运行并行指令，在渲染中这种并行方式很常见（例如，以相同的方式填充区域中的所有像素）。有些设备在同一块芯片上同时加载了CPU和GPU，这种芯片称之为集成显卡，但是用途不变。

 

CPU也可以自己渲染图形，但由于这种芯片不是专门为渲染图形而设计的，因此通常速度很慢，所以我们还是应该尽可能使用GPU。在CPU上绘制图像称为软件渲染，在GPU上绘制图像称为硬件加速。

 

另外，还值得一提的是，在使用Construct Classic之前，我有丰富的在Windows上使用C++和DirectX 9的经验。因此，我很清楚游戏构建原生级高性能渲染器需要花费的时间。

 

早期的Web

 

从历史发展来看，通常我们无法在Web上获得高性能的图形。浏览器通常都会使用软件渲染，因此图形的处理速度往往非常慢。它们还缺少适当的功能，这意味着游戏不得不采用效率低下的方式来实现图形功能，例如移动HTML元素来实现动画。Flash是当时最佳的处理技术，因此也成为了Web游戏的核心技术。

 

HTML5 Canvas

 

Construct 2于2011年2月首次发布，当时HTML5刚刚开始起步。对于游戏来说，HTML5最关键的功能就是<canvas>元素。这个元素提供了绘制图像的屏幕区域，而游戏制作就需要这样的绘图区域。

 

最初，<canvas>元素只支持“2d”上下文（通常称为canvas2d），仅提供了基本的“在某个位置上绘制图像”的功能，非常有限，而且速度还比不上DirectX或OpenGL等其他低级的图形API。其速度主要取决于CPU向GPU发出绘图命令的效率如何。在使用canvas2d的时候，你只能反复说“在这个位置上绘制这个图像”（通过drawImage），这个过程需要大量的函数调用，并且会产生大量的性能开销。获得良好渲染性能的关键在于分批处理这些命令，也就是说通过一条命令就可以完成“在这些位置绘制这些图像”。如此一来，GPU一次就可以完成了多项工作，非常适合大型并行处理器。

 

就连canvas2d最初都是软件渲染，但是浏览器制造商很快就想到，可以通过在浏览器中增加硬件加速来制作速度更快的游戏，从而取代Flash之类的插件。尽管如此，Construct 2仍然推出了canvas2d渲染器，并成为了第一批能够提供性能合理的HTML5游戏引擎的渲染器，同时还不需要任何插件。

 

我情不自禁又陷入了怀旧的心情，当时我们以为这种渲染器只能在台式机上使用。按照今天的标准，2011年的移动设备在硬件和软件方面都非常弱。在移动浏览器中运行高性能游戏的想法在当时是不可想象的。我们经历了很长的一段努力！

 

WEBGL

 

Web图形发展史上的另一个“大人物”是WebGL，它在<canvas>出现不久后迅速问世。从本质上来说，WebGL是面向Web的OpenGL（严格来说是OpenGL ES 2.0）。OpenGL是类似于DirectX的低级原生级图形API。如果你十分看重高性能的图形技术，那么WebGL是不二的选择。很明显，WebG是当时Web游戏引擎的基本功能。

 

             

 

WebGL首次出现在2011年初发布的Chrome 9和Firefox 4中。同年11月，我们首次在Construct 2 r68中发布了对WebGL渲染的支持。最初的基准测试表明，WebGL比canvas2d快4倍，后来又提高到可10-20倍之多，这是一个巨大的提升！

此外，WebGL的功能比较多，而且还支持漂亮的着色效果。我们可以利用WebGL生成复杂的批处理命令，例如一次性绘制几百个sprite，这就是为什么它这么快的原因。早在2014年，我就写了一篇文章描述Construct 2 WebGL的渲染器，尽管有段时间了，但依然可以透过这篇文章一窥WebGL渲染的优化以及批处理工作的原理。

 

过了几年后，浏览器才开始全面支持WebGL。直到2014年iOS才添加了WebGL，之后所有的台式机和移动浏览器才开始支持WebGL。起初甚至有些桌面系统都不支持WebGL，IE11于2013年才添加了WebGL，而等到每个人都升级到支持WebGL的IE11又是多年以后的事情了。因此，我们不得不在Construct中同时支持canvas2d和WebGL。

实际上，直到2018年底启动C3运行时后，我们才算真正全面删除了canvas2d——我们全面转向WebGL，并删除了所有canvas2d代码。那时WebGL已无处不在，所以我们并没有真正的损失，而且还大大简化了我们的代码库，从那以后我们终于可以只关注一个渲染器了。（实际上，Construct 3的C2运行时中仍保留了canvas2d的代码！！但是，到2021年7月C2运行时将与Construct 2一起退休，届时我们将在历时十年之后正式告别古老的canvas2d代码。）

 

WEBGL 2

 

WebGL 2是一项将WebGL的功能提高到与OpenGL ES 3.0同等水平的更新（WebGL 1与OpenGL ES 2.0同等水平）。WebGL 2在API中添加了很多功能，但对于Construct来说，这次更新的规模很小，仅增加了一些次要的限制，而且还允许我们通过调整引擎的某些部分来提高效率。对于2D游戏而言，这次更新并不是那么重要，但对于3D游戏而言，这次更新可能更为重要。

 

WebGL 2最早出现在2017的Chrome 56和Firefox 51。从未得到过Internet Explorer或Edge的支持，直到Edge切换到与Chrome相同的浏览器引擎（今年才发布）。令人惊讶的是，到目前为止，Safari仍未添加对WebGL 2的支持。尽管似乎仍在开发中，但并不是特别重要，因为如上所述，WebGL 2只是Construct的一个不太重要的更新。同时，苹果似乎确实在积极开发WebGPU（一种更高级的API），因此从长远来看重要性可能会更低，但到后期可能会有所帮助。

 

由于在Construct中添加对WebGL 2的支持仅需一些简单的改动，因此渲染器本身基本上没有变化。大多数现代设备都支持WebGL 2，但如果不支持，则Construct会切换回WebGL 1，并且所有功能在很大程度上都相同。虽然我们不清楚具体的数字，但大概有60%-80%的设备都支持WebGL 2，因此需要WebGL 1的地方仍然很多，但是与canvas2d不同，支持WebGL 2无需大费周折。

 

WEBGPU

 

转眼，我们就说到了现如今的情况：使用WebGL 2或WebGL 1，在Construct中获得高性能的图形处理。但是，技术在不断改进，目前正在开发的WebGPU可以为Web提供更快、更强大的图形技术！但是在了解WebGPU之前，我们必须回顾一下原生图形技术的简要历史。

 

OPENGL

 

OpenGL是跨平台低层高性能图形技术，WebGL就源于此，这项技术非常古老。最初于1990年代初期开发。对于计算机来说，这已经属于老古董了！实际上，现代GPU的工作方式与当时截然不同，但是OpenGL的许多核心概念并未改变。因此，应用程序使用OpenGL的方式基本上与90年代大同小异，而图形驱动程序（应用程序和硬件之间的软件）会将其转换为可以在GPU上运行的东西。

 

随着GPU变得越来越复杂和强大，最终图形驱动程序不得不肩负很多非常复杂的工作。这会加剧图形驱动程序出现故障的概率，而且在许多情况下还会变慢，因为它们必须即时进行所有的工作。类似的命运也降临在DirectX身上，尽管可能程度要轻一些，因为微软有能力在整个DirectX的生命周期中进行重大升级。在之后的数十年里，OpenGL的向后兼容性让人尤为头疼。

 

VULKAN

 

遇到无法克服的困难，我们只能寻找替代方案。于是，OpenGL背后的团队Khronos于2016年提出了全新的、完全重新设计的现代图形API：Vulkan。这个API更加接近底层、更快、更简单，而且更适合现代硬件。

 

             

然而，这也意味着应用程序为了支持这个API，必须完全重写所有图形处理代码。这种技术上的根本性转变需要花费数年的时间才能完成，所以至今我们仍然能在很多地方看见OpenGL。

 

尽管Vulkan的设计目标是成为能在所有系统上运行的标准API，但作为长期的标准，苹果提出了适用于iOS和macOS的Metal，微软也提出了针对Windows和Xbox的DirectX 12。两者的出发点与Vulkan差不多：抛掉所有的历史包袱，设计一个新的底层API更加接近现代硬件的工作方式。

 

再来说说WEBGPU

 

随着图形处理技术迈向新一代API，接下来我们要面对的问题就是通过Web做些什么。WebGL其实就是带有很多相同缺陷的OpenGL，而诸如Construct之类的高性能Web游戏引擎则可以从新一代图形API中受益良多。

 

不幸的是，与OpenGL不同，Vulkan遇到了麻烦，由于苹果的问题未能真正实现跨平台。尽管有第三方库，但iOS和macOS仅支持Metal，而Vulkan没有得到苹果官方支持。此外，就连Vulkan本身也不是特别适合Web：它太底层，甚至涉及GPU内存分配器之类的细节，以致于3A游戏引擎无法发挥最大的性能。并非Vulkan的所有功能都适用于Web平台，安全性也是浏览器中更为重要的关注点。

 

因此，解决办法是专为Web设计全新的API，不仅能够满足浏览器的使用和安全，而且还能在Vulkan、Metal和DirectX 12任何一个之上实现。这就是WebGPU，而且它似乎是唯一真正的跨平台现代底层图形API。虽然仍在开发中，但所有主流的浏览器供应商都在使用（包括苹果），而且都在试验实现。另外，我一直在为Construct构建WebGPU渲染器的原型！今后会越做越好。

 

总结

 

本文涵盖了Web图形技术的发展历史，还介绍了WebGPU的最新进展。请注意，WebGPU仍是一项正在积极开发中的实验性技术。在正式发布之前，还有很多工作要做，所以就让我们拭目以待吧。

原文链接：

https://www.construct.net/en/blogs/ashleys-blog-2/brief-history-graphics-web-1517

本文为CSDN翻译文章，转载请注明出处。

更多精彩推荐

☞华为海思超越高通，一季度国内占有率第一；苹果 iOS 13.5 优化 Face ID；Ruby 2.4 结束支持 | 极客头条
☞10 款值得珍藏的 Chrome 浏览器插件
☞当互联网码农遇见国企老同学
☞AI图像智能修复老照片，效果惊艳到我了
☞程序员内功修炼系列：10 张图解谈 Linux 物理内存和虚拟内存
☞当 DeFi 遇上 Rollup，将擦出怎样的火花？
你点的每个“在看”，我都认真当成了喜欢