什么是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图形未来希望”的盛 名。

相較於 Firefox 1.x，後繼的 Firefox 2.x/3.x 在圖形顯示方面有相當大的進展，很大層面歸功於引入 Cario 向量圖形程式庫來處理網頁繪製，而 Skia 就相當於扮演 Cairo 的角色，不過更輕量些。快速發展的 WebKit 儼然是從桌面應用跨足移動裝置之網頁引擎解決方案的首選，Apple 與 Google 都有為數可觀的全職工程師投入，拜網際網路的威力，也有其他廠商與團體個人積極投入開發，目前 WebKit 支持的圖形函式庫計有 Cairo, Gtk+, Qt4, WxWidgets, Cg (Mac 的非開放原始碼函式庫), Skia 等等，並以 WebKit 中 class GraphicsContext 處理前述圖形函式庫的實做，可針對不同平台的特性，規範不同平台所需的巨集與成員，詳情可參考程式碼 WebCore/platform/graphics/GraphicsContext.{h,cpp}。
Skia 以 C++ 實做，程式碼約八萬行，基本某些未知的因素，可參考的文件相當有限，但 Chromium 的 SVN log 與程式碼則是現在最完整的文件，以下是其特徵：