The WebGL potential - WebGL的潜能 Back

• 原文链接 : The WebGL potential
• 原文作者 : typedarray.org
• 译者 : aleen42
• 校对者 : 暂无
• 状态 : 待校对

WebGL 的潜能

       最近，关于 WebGL 将广泛兼容于各平台的谣言炙手可热，尤其是 IE 浏览器。当然，随着谣言的传递，一组真正可跨平台的 GPU API 也随即面世。在我看来，倘若谣言得以实现，那么这将会在一定程度上影响到 Web 开发中的许多观念。在关于人们如何开发交互性内容的观念上，这影响显得尤为明显。当然，即便这只是一个谣言，我也希望它能推动 Web 开发领域的发展。

使用 WebGL 也可以处理二维图像

       WebGL 是一组针对 OpenGL ES 2.0 功能集所开放的基本 JavaScript 底层接口（其背后实际上运用了 OpenGL/ES 2.0 或 DirectX 的技术）。然而，大家却误以为 WebGL 仅仅可以处理三维图像。其实，我们不仅能像 three.js 那样，利用这些底层接口重构出三维图像中的高级结构。而且，还能简化二维图像中的基元，以便我们去处理二维图像。众所周知，两个三角形便能够形成一个矩形，且该矩形能承载一段纹理内容。而这便是 GPU 加速渲染二维图形的原理。此外，当 WebGL 无法力所能及的时候，这也是诸如 Cocos2D-x 或 Pixi.js 等大部分二维图形框架基于 Canvas 的一种回退机制。也许你会问，若我想实现复杂的滤波或颗粒度效果呢？对此，WebGL 也提供了一种可编程管道（着色块（shader））的方式，以实现图像的可再生化（reproducible ）。

       曾几何时，我们在 Flash 中开发 Stage3D 库时，便想着要尽可能地去暴露底层的接口，以使得开发者可以从顶层灵活地开发框架。特别是对于游戏开发者来说，他们过往曾迫切需要通过区分颗粒度的等级来控制一切，并保持有高效的性能。可是，在另一方面我们却了解到，大部分开发者会热衷于使用他们熟悉的高层 API 分离基元，而并非底层的 GPU 基元。所以，Starling 框架由此诞生。正如 Rivio 通过使用该框架，把 Angry Birds 快速地集成于 Facebook 中那样，它不仅能基于 Stage3D ，快速地应用于二维图像的开发。而且，还能像 Zynga 那样，集成 Ruby Blast。

       当然，WebGL 除了有助于开发游戏之外，它还能增强网页中用户交互的体验，如我们所多年熟知的数字化营销型网站 thefwa.com 或传统通过 Flash 所实现网站等。除此之外，WebGL 还彻底改变了开发者构建移动端应用的方式。也就是说，任何在手机上所能体验且带有平滑效果的 UI 组件，其全都是通过 GPU 所加速，并由 OpenGL ES 2.0（iOS、Android）或 DirectX（Windows 8）服务支持。当然，我也冀望以后能有越来越多的 UI 框架出现，并提供有基于 WebGL 上进行 GPU 加速的 UI 组件。Feathers 便是其中之一。

       那么，这就意味着 WebGL 能解决所有的问题吗？当然不是。这实际上需要取决于具体的开发情况。例如，对于多文本内容来说，如开发一个新闻页面、一个论坛或一个简单的表单应用时，使用一个由 CSS 定义样式的传统 DOM 会更为有效。这是因为，CPU 善于处理像字体编译或矩阵计算等事情。换而言之，若能集两者之大成（基于 CPU 或 GPU 的编译器），那么，这样的混合将会变得无比强大。

隐式 vs 显式

       如今，开发人员为了在浏览器中追求更高的性能，他们会倾向于构建出一种“欺诈”系统的技术。当我在 stackoverflow 上看到关于“性能欺诈”的对话时，不禁感到些许不安。这是因为，所有的这些项目都会因为开发者的个人臆想，或更坏情况下所产生的副作用，而导致终结。近年来，人们常会谈及那些使用 GPU 加速渲染 DOM 的神奇方案。可是，他们却不明白，这绝非易事。当一个用于显示元素的列表挂载了多个需要显示的元素时，GPU 是很难对其有所优化。甚至包括那些复杂的嵌套、蒙层、混合以及通过 JavaScript 或 CSS 所控制的元素。可是，随着开发者热衷于使用如斯代码去加速渲染 DOM 元素时，你就会发现，在使用的过程中，这些所谓的“加速”并不适用于成千上万的开发情况。也正是这样的一种现象，导致如今的开发者难于对表层的内容进行开发。当你认为在背后悄然运行的代码不可控时，这就意味着开发终将败于此类“鸡汤”式建议：

在使用这些属性之前，你需要确保没有嵌套任何的元素。而且，你还需要确保 alpha 值已被设置成零值，并保证不会从 DOM 结构中移除该元素。

       其实，开发过程中你所需要关注的理应是暴露底层的接口（如 WebGL），以使得其他开发者可以开发更为高层的框架，而这也正是最灵活的一种开发模型。当然，性能上的任何问题或漏洞，都可以通过修复来解决，而框架结构的舒适问题，也可以通过替换来解决。但是，要谨记一点的是，代码基于内容，而并非基于运行环境，即浏览器。而这恰恰就是 DOM.js 背后的核心思想。

       最近，有一个方案提到，可以通过使用 translateZ（CSS3）去强制 GPU 进行加速。在此，我再重申一点：该方法不仅属于一种非法侵入的行为，而且还带有一定的副作用。其原意是用于开发三维图像的效果，但如今开发者只用在二维图形上的开发，却没真正地了解到在背后所发生的隐式事件。事实上，所“加速”的 DOM 元素会进行点阵化（一般如果该元素拥有大量的内嵌子元素，即便简单，也会非常耗时），然后，位图会被上传至 GPU （要记住你是无法调用任何的上传 API）。然后，才重新渲染于页面中。顺带一提，若位图的纹理过大，将会严重“挫击”在内存外运行的其他设备，并使得开发者“坠入”黑暗。

       再次重申，高级开发者在开发高层次框架时，可以利用上所暴露的底层接口（在这里指的是使用 JavaScript 语言），然后让其他开发者有使用 API 的机会，并了解这些接口在背后的显式事件。所以，该过程可谓副作用最小化。至于那些尝试使用该高层框架去解决事情的人，他们则会有机会看到框架背后的实现，并了解问题的存在及其所隐藏的工作原理。举个例子来说，作为一个 Flash 开发者，他们都会采用相似的技术进行开发，如过往多次使用 cacheAsBitmap 框架来提高性能。当然，凡事皆有两面性。看似纸上谈兵，可一旦开始使用该 cacheAsBitmap 框架，你就会意识到该 API 的“怪异”，且用于有效构建过程中的种种苦难。很久以前，我就通过一篇文章来阐述为何 cacheAsBitmap 是一个邪恶的东西以及同样的道理，我们如何能用底层的接口以最小化的副作用去完成。

高层框架的重要性

       大多数开发者会采用一些自己所熟知的高层框架来完成产品的开发并同时使产品保持有良好的性能，而非深入探究 WebGL 中的 GPU 编程细节。正因 WebGL 对于大多数 Web 开发者来说，缺乏友善的使用方式，所以，诸如此类高层的框架则显得尤为重要。当然，这实际上还源于 WebGL 在90年代是通过水平面的方式，从 OpenGL 直接引用到 JavaScript，因而导致目前的状况。

       困难莫过于 GPU 编程中的细节过于繁琐，以及 WebGL 所提供的 API 入口过多，以致于开发者运行脚本或捕获脚本中的错误时，陷入冗长且繁缛的过程。而对于 Web 开发者来说，这是一件非常鸡肋的事情。然而，我们应该庆幸的是，大量基于 WebGL 的 JavaScript 框架成品如雨后春笋般地出现，给开发者提供了不同的选择。

仍属 Web 开发范畴？

       WebGL 与 2D Canvas 类似的是，它还会支持于 Canvas 内部的技术实现，并使得 Canvas 成为了一个相当隐秘的黑盒。尽管，这种模型对于游戏开发或部分交互模块开发来说并非不可接受，但是，这却阻碍了搜索引擎的优化及引擎对内部数据的访问。那么，就会产生这样的一个问题。随着越来越多像应用程序那样的二维交互内容采用 WebGL 的技术支持，我们该如何访问其中的内容呢？目前，由于该模型的局限，我们尚未能实现。可是，我认为这迟早是要改变的。当然，我不禁要问道，“为什么我们目前只能访问到经典的 DOM 元素？”

       针对该问题，我在这里只想强调一点：“WebGL 会以新的创造方式去推动 Web 领域的发展。”

推动 Web 领域的发展

       在 Flash 的 Stage3D 框架出现之前，Web 领域中图像处理的主要瓶颈在于图像通道的处理上。当然，ActionScript 3 提供了一种可行的方案，使得大部分的展示列表得以实现，或使得图像能依托 BitmapData 以位块的形式去传输内容。但是，Stage3D 的推出使得该情况骤然改变。由于 ActionScript 3 成为了开发者开发过程中的一种限制，因此，开发者从那时候就开始逐步开发高层的框架，并把大量的核心代码移植出来。不然，这些代码只能传统地依赖于原生 ActionScript 3 而运行。倘若如此，诸如树的遍历、边界访问或矩阵计算的代码终将会给 VM 和 CPU 带来巨大的压力。

       协同地利用 CPU 和 GPU 去运行代码，是获取高性能的一种方式。因为，当 CPU 资源被占满时，GPU 若不能及时地去处理过剩的计算任务，那么，性能显然会骤降。这样的情况对于在 JavaScript 中使用 WebGL 的开发者来说，无疑是一种压力。这就是为何我们建议在使用 WebGL 之前需要引用 asm.js 以支持像 Unreal engine 这样的图形引擎。当然，我冀望该建议能最终推进 JavaScript 性能上的发展。不管你对 asm.js 喜欢与否，通过它，我们才有机会去尝试解决那些，与未来内容开发密切相关的问题。

       若您对 asm.js 感兴趣，不妨阅读一下 John Resig 最近所写的一篇文章。