显卡加速网页渲染

Firefox的锐意进取将给对手带来前所未见的压力，显卡加速网页浏览即将进入现实，而Firefox将无可争议成为最快的浏览器。微软将首当其冲面对这些压力，显然微软不会打算以IE 7.0应战，但IE 8.0似乎还没有将显卡加速渲染功能考虑在内，那么它就很难有效遏制Firefox 3.0/4.0对市场的进一步蚕食。

有大量的网站只是针对IE设计，使用Firefox浏览时容易出现版面不正常的情况，另外诸如网上银行之类的重要应用也都无法支持Firefox平台，只要这些问题无法得到最终解决，Firefox都很难再有突破性的提高。遗憾的是，Firefox的开发者和用户们都无力改变这种不利的状况，但这并不意味着Firefox的技术突破之旅结束，开发者将大踏步朝向新的目标挺进，并将带来一款更具革命性的产品，它就是我们接下来要介绍的Firefox 3.0。

Firefox 3.0的技术突破
广泛认为，Firefox的优点是渲染速度更快、安全性更好以及扩展性更强，对于后两个优点外界没有异议，但在渲染速度方面却存在不小的分歧。我们知道，浏览器的网页渲染功能是由核心的渲染引擎提供，Firefox是以开源的Gecko核心为基础开发，其性能就取决于Gecko。在标准的网页渲染中，Firefox的性能的确胜过IE（主要是IE 6.0），但它的资源占用率要高一些；IE虽然渲染速度略慢一些，但它的资源占用率低。出现这种情况并不奇怪，因为Firefox的哲学是“既然系统资源是空闲的，那么为什么不充分利用？”，换句话说，Firefox是以占用更多的硬件资源来换取更快的渲染速度。而微软IE浏览器与操作系统紧密耦合，资源占用率方面存在先天优势，但它的渲染引擎明显不怎么样，本次匆忙推出的IE 7.0也更多是外在功能的提升以及UI界面的改良，最关键的渲染核心没有被升级，因此在网页渲染速度方面，Firefox 2.0仍将拥有一定的优势。

遗憾的是，Firefox 2.0同样没能解决之前版本存在的重大弊端。如果打开包含许多大图片的网页，CPU占用率就会飚升，甚至高到100%，导致系统操作出现短时的卡死现象。与之类似，如果网页包含很多Flash动画，CPU占用率也很容易升到100%，除了与Flash动画本身就较耗用资源有关外，与Firefox的插件式平台结构也有关联。Adobe的Flash播放工具是以插件的形态与Firefox协同，过去Adobe并没有将Flash代码开源，开发者无法将它集成于Firefox的核心内，这就对渲染效率带来不利的影响。由于现在的网页绝大多数都包含大图片和Flash动画，Firefox渲染速度快的优势变得不再明显，反而容易出现资源占用率高的问题，尤其是那些安装了许多扩展插件，且硬件平台又不够强劲的用户，会明显感觉到Firefox高资源占用带来的烦恼。对于这些问题，开发者心知肚明并积极着手改变，将于今年推出的Firefox 3.0将承载用户的希望。

图1 Cairo可以实现半透明、阴影、边缘抗锯齿等复杂的图像效果，更重要的是，这些效果都可以由显卡渲染完成。

Firefox 3.0的开发代号为“Gran Paradiso”，按照Mozilla基金会的计划，Firefox 3.0将于2007年三季度正式推出。与现有的2.0不同，Firefox 3.0采用了全新的Gecko 1.9渲染引擎，这也是Firefox 3.0解决资源占用率高的关键。相比Firefox 2.0所采用的Gecko 1.8引擎，Gecko 1.9在图形架构方面有了根本性的改变。Gecko 1.8采用传统的gfx图形架构，它是一种软件方案，由CPU来完成对2D图形图像的渲染；而Gecko 1.9改用“Cairo”图形架构，Cairo可以借助GPU来负责渲染2D图形图像，相当于实现网页渲染的GPU硬件加速，这样，CPU就被完全解放出来。由于现在的GPU普遍都拥有非常强劲的硬件效能，承担网页渲染任务会非常轻松，因此从理论上说，Gecko 1.9引擎既可以实现更快的渲染速度，又能够大幅度降低CPU资源占用率，实现真正意义上的飞跃。

图2 Firefox 3.0可支持SVG可缩放矢量图形，渲染工作由显卡完成，这样就解决了CPU资源占用的问题。

为了完成这个目标，开发者必须重构Gecko的底层代码，即逐步将原有的gfx图形代码移除，并将Gecko重新构建于Cairo的基础之上，这一工作目前正在有条不紊地进行，并将在明年中期完成；而到明年的第三季度，我们就能看到全新的Firefox 3.0出台。

什么是Cairo
绝大多数读者可能对“Cairo（开罗）”这个名字闻所未闻，这并不奇怪。Cairo是一个跨平台的开放源代码的矢量图形函数库，可以提供高质量的显示和打印输出。由于Cairo的主战场一直是在Linux的Gnome桌面环境领域，Windows用户对它感到陌生并不奇怪。Cairo内包含一个Glitz函数库，通过这个函数库，Cairo能够使用OpenGL或X Render扩展的硬件加速功能来绘制图像，如果你的显卡拥有一定的OpenGL性能（GeForce 2 MX级别以上即可），那么由GPU来负责2D图像的绘制图像的工作会变得异常简单，而所有基于Cairo的应用也将从中受益。

作为系统应用的基础构件，Cairo提供了一个稳定的用户层API，它可以提供现代化的图形处理管理能力，例如绘制与填充、映射转换、合成以及改变Alpha半透明效果、高清晰文本显示等等，并且能够在不同的媒介上实现相同的显示输出。这个概念并不难理解，简单点说，它与OpenGL、DirectX等图形API实际上是类似的东西，只不过OpenGL和DirectX属于3D加速的API，它们都可以让应用程序直接与图形硬件紧密地协作；而Cario则是针对2D图像绘制的API，它向更高级的应用程序提供了一系列的图形处理功能，同时又借助OpenGL API实现与图形硬件的互动（Cario与OpenGL的衔接由Glitz函数库完成）形成，借助GPU的运算能力来处理2D图像相关的应用。那么，如果我们将Cairo作为应用程序的图形架构，这个应用程序所涉及到的所有图像处理任务都可以由GPU来完成，在这一方面，专用化的GPU显然要比通用的CPU更具效率。这样，应用程序不仅可以实现更丰富、更复杂的图像效果（如抗锯齿、半透明、阴影、映射转换、变形等等），同时还能在低CPU占用的前提下保证流畅的运行。

Cairo图形架构最主要的应用场合就是Linux的Gnome桌面环境。目前Gnome已经可以对Cairo完全整合，这样我们就可以实现更平滑、更富有动感的显示，但由于许多显卡都缺乏优秀的Linux驱动，Gnome中的Cairo仍未与OpenGL全面整合，必须依赖CPU进行图像处理，这就对系统性能带来一定的不良影响。不过这种局面将很快扭转，nVIDIA、ATI和英特尔都加大了对Linux驱动的开发力度，越来越多Linux用户将成功驱动显卡，届时Cairo将从显卡的OpenGL渲染能力中充分受益。除了Gnome之外，Gecko 1.9及以后版本也都将基于Cairo构建，这就意味着网页的渲染工作将可以由效率更高的显卡来完成，从而实现浏览性能的飞跃。

Cairo采用开放性与模块化的设计，它可以拥有很多功能不同的后端（基础性的模块），支持多种输出设备，其中常见的后端函数库包括以下几种：
● 图像 以内存图像缓冲区（in-memory image buffers）为目标，该图像缓冲区可被保存成文件，或者被那些缺乏本地后端的图形系统调用。
● gl 通过glitz库来绘制图像，它包括GLX和AGL两个类型，分别针对Unix平台和苹果Mac平台。
● png 对png格式提供支持，允许应用程序通过Cairo直接生成png格式的图像文件。
● ps 允许Cairo生成一个PostScript文件，适合高质量打印输出─目前ps后端所生成的是点阵内容，并与前面介绍的“图像”后端连接。
● xlib 为应用程序提供访问X服务器功能的底层函数。
● xcb 功能与xlib相似，但使用XCB（X protocol C-language Binding）接口，具有精简、快速、可支持多线程执行的优点。

除了这些原本就有的后端外，Cairo的后端还包括pdf、svg等，分别可对pdf格式和svg格式提供原生支持，这将能显著提升pdf文件和svg矢量图形的渲染速度。现有PC还缺乏这样的能力，不论你拥有多么强劲的CPU，在浏览pdf文件或者放大缩小svg矢量图形时都会感觉到显示的停滞感。但如果你的图形系统基于Cairo构建（例如Gnome），并且拥有一块主流性能的3D显卡，执行pdf、svg相关操作将会变得非常流畅，从而有效提升用户的使用体验。显然，基于Cairo的Gecko 1.9渲染引擎也可以获得相同的效果，如果你直接在Firefox 3.0浏览器中打开pdf文档或者svg矢量图形，内容渲染速度将大大快于以往，并实现真正意义上的同步显示。

注：可缩放矢量图形（Scalable Vector Graphics，SVG）是基于可扩展标记语言（XML），用于描述二维矢量图形的一种图形格式。SVG由W3C制定，是一个开放标准。

借助Cairo，Gecko 1.9可以把大部分的显示工作交给显卡（GPU）来完成,这样一来，Gecko在那些有3D显卡的机器上就会变得非常高效；而它对硬件要求并不苛刻，如i965G、nVIDIA C61D之类的整合芯片组即可很好地满足需要。在显卡的帮助下，Gecko 1.9可以获得超越对手的一流渲染速度，而设计师们也可以开始考虑在网页中实现更现代化的2D图形效果，例如填充、描旁、去背、映射转换、Alpha透明支持等等，尽管今天的浏览器都不可能承担如此沉重的渲染任务，但在浏览器实现GPU加速之后，互联网上的网页将会变得更加丰富多彩。

为何使用Cairo
观点纷纭是开源业界一个非常有趣的特点，全球各地、不同文化的开发者都有自己鲜明的观点，而这些观点经常又会发生碰撞。Cairo曾被誉为“Linux图形未来希望”，Mozilla基金会的开发者也选择Cairo作为未来Gecko的图形架构，但有许多自由程序员并不认为此举英明。在非正式的测试中，Anti-Grain Geometry的效率明显高于Cairo（Anti-Grain Geometry，一个开发中的高性能2D图形API，采用C++语言编写），甚至传统的软件绘制方式都比Cairo来得快。许多人都困惑为何Gecko选择Cairo作为图形渲染解决方案，遗憾的是，Gecko的解释似乎不那么让人满意：

第一个理由是“C++效率不佳”，Gecko和Gnome的开发者都抱有这种看法，它们更喜欢传统的C语言，但C++更好还是C更好注定是没有答案的命题，Gnome（C编写）阵营与KDE（C++编写）阵营为此打了无数的口水仗，至少在Cairo身上我们看不到C优于C++的地方，而Anti-Grain Geometry项目都采用C++语言，但它的效率要明显高于Cairo。

第二个理由是“Cairo拥有一个完善的硬件加速解决方案”。从一开始Cairo便宣称将会利用glitz这样的后端实现硬件加速的矢量图形绘制，达到软件绘制无法达到的效果，但颇富戏剧性的是，现在的Cairo仍然比所有这些用软件绘制的引擎都慢得多（如Anti-Grain Geometry就只是纯软件的引擎）。这一问题主要是由glitz的Bug所造成的，导致Cairo无法真正实现硬件加速，而让人郁闷的是，glitz后端的开发者David Reveman一直都忙于XGL的开发，没有余力来解决问题，这也导致Gecko与Cairo的整合进程波折不断。

第三个理由是“Cairo支持PDF/PS输出”。这个功能看上去非常有诱惑力，但不少人认为这个功能没有多大的用处，毕竟不会有多少人需要把网页输出到PDF/PS。

由于Cairo存在软件绘制效率低下的问题，一些开发者就建议Mozilla渲染两条腿走路的方案：在使用glitz后端实现OpenGL硬件加速的同时，整合一个高效率的软件2D图形引擎（例如Anti-Grain Geometry、Xara等）。勿庸讳言，硬件加速2D渲染是大势所趋，Anti-Grain Geometry和Xara目前都是纯软件方案，难以适应长远发展的需要。另一个选择就是采用专门针对2D图形加速的OpenVG API。Cairo的glitz后端缺乏强有力的开发支持，也许得采用软/硬混合的妥协方案，而且硬件加速是通过“Cairo->glitz后端->OpenGL API->GPU硬件”的桥接方式实现，若能直接选择OpenVG API构建，那么无疑能够进一步提高Cairo的渲染效率。第三个备选就是“Amanith”2D图形API，它的功能同OpenVG类似，同样基于OpenGL构建，但Amanith API只是针对C++应用。

无论Cairo朝着哪一个方向前进，现阶段它都必须解决好软件绘制效率低下和glitz后端的整合问题，Cairo项目需要更强大的开发力量，如果这两个难题能够在未来8个月内得到解决，那么Cairo会成为一个非常理想的2D图形引擎，Gecko 1.9/Firefox 3.0将会变得更具吸引力。多数开发者们都希望未来Cairo能够实现更最直接的OpenGL加速，这样它才能真正无愧于“Linux图形未来希望”的盛名。

Gecko与Cairo融合
实现Gecko与Cairo的融合是一项费时费力的工作，开发者并没有试图一下子将Gecko的图形架构完全转为Cairo，而是以模块化的方式循序渐进地进行。事实上，早在Gecko 1.8/Firefox 1.1版本中，开发者们就着手Cairo的整合工作，如Cairo中的Canvas、SVG矢量图支持模块已经在Gecko 1.8中实现，而非Cairo的SVG实现方式（例如GDI+）仍得到保留，另外Gecko 1.8/Firefox 1.1的Windows版本也没有实现SVG功能。另外，GPU硬件加速功能也没有在Gecko 1.8中实现，依然只能通过软件的方式进行页面内容渲染。基本上，Gecko 1.8只是实现最初级的Cairo整合，图形架构仍然是基于2D的gfx API。除了Firefox 1.1外，后来的Firefox 1.5和现在的2.0版本也都是采用Gecko 1.8引擎，这三者的差异更多在浏览器外壳以及对安全功能的增强。

图3 Gecko 1.8初步导入Cairo，但仍然是以传统的gfx图形架构为基础，只能由CPU负责所有2D图像的渲染工作。

而在Gecko 1.9引擎中，Cairo模块将被完全实现。首先，传统的2D API gfx被停止使用，相关功能完全由Cairo接管；其次，Cairo将支持Glitz函数库，借助OpenGL来实现HTML显示的硬件加速；其三，Cairo中多种不同的后端将被补充完整，以使Cairo可支持更丰富的功能，例如实现pdf、svg浏览硬件加速，或者直接进行页面格式转换等等。完成这些工作之后，Gecko 1.9就可谓脱胎换骨，虽然它的版本只是升级了0.1个阶次，但Gecko 1.9完全可以说是一个崭新的渲染引擎。

图4 Cairo成为Gecko 1.9的图形架构，它不仅可以让显卡来加速网页渲染，而且可支持丰富的新功能。

按照计划，Gecko 1.9将在2007年第二季度完成，Firefox 3.0浏览器则会在随后的三季度正式推出，也就是说，我们还需要一年的时间才能看到Firefox 3.0真正成熟。毕竟对开发者而言，从Gecko 1.8到1.9的技术难度超乎想象，比如在使用Glitz之后，开发者发现程序存在严重的Bug，最坏的情况是可能导致整个计划的延迟。所有人都知道基于Cairo构建是正确的方向，但图形架构的整体转换非一日之功，出现一些小意外在所难免。

图5 Firefox版本与Gecko核心发展路线图

在Gecko 1.9之后，Gecko 2.0将成为新的明星，顺利的话Gecko 2.0将会在2008年初发布，Mozilla基金会也将随后推出Firefox 4.0，Firefox 4.0最重要的新特性就是对Flash提供原生支持，通过GPU来加速Flash播放，在3.0基础上又向前迈进了一大步。

Firefox 4.0将原生集成Flash
网页中大量的Flash动画是导致浏览器CPU占用率高的祸首，无论IE、Firefox、Opera、Konqueror（Linux KDE桌面环境的浏览器）还是苹果Safari都饱受其苦，其中又以Firefox、Opera、Konqueror和Safari受到的影响最为突出。关键原因在于这三者都不具备Flash播放功能，必须通过插件的方式加以支持，导致其效率不高，而浏览器的Flash插件则是由Adobe公司提供。Windows平台的情况要好一些，Flash插件版本的升级完全与技术标准同步，但Linux/Mac平台就没有这样的待遇。目前Windows版Flash播放插件为9.0版本，而Linux一直都停留在7.0版，最近推出的9.0版停留在很初级的测试阶段，存在大量的Bug，对于Linux/Mac平台的非IE浏览器来说更是雪上加霜。

Adobe公司并未考虑通过加大技术力量来解决这一问题，而是采用一个十分英明的办法，将Flash源代码直接捐赠给Mozilla基金会，这也是Mozilla基金会有史以来收到的最大一次代码捐赠。Adobe表示未来将把最新的Flash源码直接提供给开源业界，以实现未来浏览器与Flash播放功能的更佳整合。有鉴于此，Mozilla基金会决定建立一个名为“Tamarin”的新项目，专门用来管理使用Adobe所贡献的代码，而新项目将由Adobe与Mozilla共同管理监督，相关源代码将被下一代“SpiderMonkey（Gecko的JavaScript脚本引擎）”直接整合。除了贡献Flash源代码外，Adobe还将向Mozilla基金会提供“ActionScript Virtual Machine（简称AVM）”虚拟机软件，该软件是Flash Player播放器中的一部分，它的功能就是负责对ActionScript代码的解释。ActionScript是Adobe Flash产品平台的脚本解释语言，该语言可以实现Flash中内容与内容，内容与用户之间的交互，目前它的最新版本为3.0。与广泛使用的Java Script和微软Jscript一样，ActionScript完全符合ECMA International的ECMAScript标准。

得益于Adobe的慷慨贡献，未来的Firefox浏览器将能够原生支持Flash，而不必再依赖效率低下的扩展插件，再借助Cairo实现GPU硬件加速，网页Flash占据系统资源的现状将成为历史。Mozilla基金会表示，Adobe贡献的Flash代码将在2008年上半年融入到Firefox之中，从路线图来看应该就是Gecko 2.0引擎和Firefox 4.0浏览器，相信届时Firefox 4.0将实现令人难以置信的超速浏览体验。