作者：
Keith Packard
XFree86 Core Team,SuSE Inc.
keithp@suse.com
原文： http://keithp.com/~keithp/talks/usenix2000/render.html

译者：
zleil cfb0d4b6.le@gmail.com cfb0d4b6_le@sina.com zleil@yahoo.com.cn

注：本人技术水平和翻译水平有限，译文可能存在相关问题，此wiki文档可由他人编辑修改。读者如发现错误，请邮件通知我，可在译者处留下自己的联系方式，非常感谢。

X11规范[SG92]最初设计和实现于1987年。应用程序（译者：以下都指图形应用程序）和硬件在这十三年间不断向前发展，然而XWindow系统核心仍没有大幅度更改。X11R4包含了对主流X服务器架构的最后更改。最后被广泛应用的X服务器功能扩展是形状扩展[Pac89]（译者：用于生成不规则形状窗口），该设计思想提交于1989年圣地亚哥Usenix冬季会议。#|
在过去几年间，廉价Unix桌面系统的出现导致了一种新的用户界面库被开发，然而已有的X渲染模型并不能很好的发挥该库的优势。一种新的2D渲染模型被提出以适应这种新的应用。本文介绍了与此相关的问题及解决方案。

虽然窗口系统远不是一些渲染原语的集合，然而渲染原语却最能限制应用程序的功能。（现在的）X渲染模型是针对十五年前的工作站硬件设计的，对当今应用程序而言，它存在很大局限性。
随着应用程序不断向前发展，X协议逐渐退化成一个图像传输机制。应用程序在客户端缓冲区内进行渲染，然后将结果传送到屏幕显示。当应用程序与X服务器运行于同一台机器时，共享内存机制被用于传送图像到X服务器；但当应用程序和X服务器分布于网络中不同机器时，这种图形传输机制存在严重的性能问题。
许多图形加速卡为应用程序提供了必要的加速操作。仅当X服务器实现了这些加速操作功能后，X客户程序才能使用图形加速卡提供的加速功能。

我们因该站在X渲染技术诞生的那个时代去理解它。回顾1987年的图形工作站，一个1MIPS的机器就展示了那个时代的技术水平，拥有彩色桌面系统就已经是很幸运的了，当然是8位色，带一个调色板。一些使用SGI工作站的头脑发热之人偶尔会提及真彩色硬件，但大部分人连想都不敢想。用硬件加速是可能的，但是通常不会快于软件，并且很难在程序中使用，编码实现困难。
PostScript[Ado85]代表那时最先进的2D渲染技术。工程师认为用精确的数学公式对目标对象进行定义是最好的。PostScript提供复杂的字体技术，并将其嵌入到当时的打印机内，然而桌面系统使用的却是位图版本的字体。
与此同时，一组网络协议产生了，并且硬件黑客们决定更新XWindow系统。他们中间没有一个计算几何学家，也没有现代的英特网技术可借鉴 (plt: 也没有现代英特网上的资源来帮助他们进行设计)。(当然，一种惯常的做法是赶快将自己的想法完成，并发布出去)。正在筹集资金开发sample服务器（译者：最初的Xwidnow实现样本，文中sample服务器表示Xwindow的实现样本）的Digital为开发人员制定了计划表，与此同时，来至MIT的项目Athena正开发这越来越多的X10机器。
因此，他们选择了PostScript红皮书，并开始撰写相应规范。新的窗口系统有很好的扩充性，只需增加相应的扩展功能就可以弥补最初的设计缺陷。但开发人员没有认识到红皮书的缺陷，它不足以描述某些原语的实际实现，同时各开发人员也没认识到制定渲染标准有多困难。
在那个时代，图象处理是PostScript的最大弱点。由于打印机是黑白的，所以PostScript并不需要任何复杂的图像混合操作。此外，X是一个交互式协议：一张经alpha渲染的满屏图像看起来就像xxxxxxxxxx（译者：实在不知道怎么翻译这句话）(在监视器上从上往下滚落的液滴)
粗糙的线条是另一缺陷。红皮书描述了一个画线算法：一支圆头笔（比心是圆圈状）沿着一条线路上移动，圆圈经过的像素都属于被画线。此算法划出的线在相应线路上粗细不均，效果看起来非常糟糕。（understanding of the problem, Adobe kludged around it. 此句不知如何翻）。John Hoby解决了此问题[Hob85]，但解决方法没有公布于斯坦福大学之外，X社区在若干年后才知晓该方法。
X没有类似PostScript路径的概念，它仅提供画直线的功能和画轴平行于坐标轴的椭圆的功能。为什么被画椭圆的轴要平行于坐标轴呢？因为当时谣传画轴不平行于坐标轴的椭圆的算法已经被申请了专利，而开发者认为X因该是一个不带任何技术专利的系统。实际上那时该专利（在很多年前公布的[Pit67]）已经过期了。
在一次会议上，X11小组成员发现他们都不懂样条曲线，并决定不实现画样条功能，宁缺毋滥。同时，子像素定位技术（sub-pixel position）将使用32位来描述一个坐标值而不是16位，这将使渲染原语大小翻倍，该技术被认为是对网络带宽的浪费而未被使用。
大家都期望于将来能利用X的扩展功能来解决以上问题。然而，X的使用越来越广，市场要求各X服务器之间必须具备兼容性。创建一个仅在某些X服务器内使用的扩展功能势必造成应用程序之间的不兼容性，所以整个渲染模型一直停滞不前。

即使不对比一些新的渲染技术，核心协议体系仍存在一些根本性的问题。

• 缺乏模板填充操作（译者：不知stenciling operation这么翻译行不行？） X10提供一个对区域填充的模板填充操作，但X11舍弃了它。可以用CilpMask来模拟模板，但在X服务器的sample服务器内ClipMask的实现非常低效，所以使用模板填充操作是不切实际的。
  模板填充操作可被用于加速外界（译者：即X服务器之外）不可见的渲染原语，应用程序使用一个单色位图描述一个形状，然后用模板填充操作将结果绘制到屏幕上。所以开发者在sample服务器内部实现了模板填充操作以供上层原语使用。
  
• 线和弧线的分离 轴平行于坐标轴的弧线是没有意义的，他们从线中分离出来更是没有意义。这种分离使得我们无法归一线和弧线。作为一个特殊的例子，在一个矩形内绘制一个轴平行于坐标轴的弧线，宽或高（译者：椭圆的长轴和短轴）为零时弧线被定义为线。
  
• 文本绘制无垂直方向限制 在渲染亚洲语言文本时，垂直方向限制是必要的，同时字体旋转也应该被考虑。
  

在建立一个新的渲染系统时，忽略已有系统的优点是不明智的。

• 精确的像素化（译者：即渲染原语能确定它所绘制的每个像素的坐标坐标）
  除了极少数原语外，每个X操作原语都精确的描述了像素化请求。这不仅允许在X服务器执行周期内重复渲染，更为重要的是能自动化渲染代码的测试过程。规则可能被破坏，但是他们的存在是至关重要的。
  
• 像素值，而不是颜色值 为渲染系统提供一个暗含的像素值，这样就可以实现一个用户空间的颜色系统（译者：通过修改像素值与颜色的映射关系），反过来则不行。另外，如果要向应用程序提供对像素值的布尔运算操作，像素值必须对外可见。
  
• 允许所有渲染变换（译者：rendering permutations不知道翻译成渲染变换合适否） X允许应用程序结合一系列光栅化操作（如XOR）来渲染点阵字体。这些光栅化操作可以和所有原语（不仅仅是ImageText原语）结合共同完成渲染过程。这样就能对屏幕上所有待画物实施一致的抖动技术或可逆的XOR光栅操作。
  

很明显，当今的Linux机器对新渲染模型的需求是最强烈的。KDE、Gnome和Enlightenment三个系统证明了2D图形世界远远把Xwindow系统甩在后面了。这些应用是用了复杂的渲染原语，如轮廓字体、三次样条。他们使用反走样技术来提高图像质量，使用alpha合成技术来混合（blend）图像。
需要实现什么样的渲染已很明显了，现在的问题是渲染应该发生在什么地方。应用程序将不断发展，X要么跟上，要么出局。许多新的应用程序使用工具箱库提供的高级渲染模型，这个现实促使一种X扩展功能的诞生。这项扩展功能要求符合工具箱库的渲染模型，且允许应用程序逐步采用该扩展功能，同时需对工具箱库作此改动：当扩展功能可用时，工具箱库使用该功能来加速各项操作，否则工具箱库使用针对旧X服务器（没有该扩展功能的X服务器）的客户端渲染。

当代2D应用程序对渲染系统的要求是类似的。通过分析已有的应用情况，仔细的选择原语，我们可以构建一个合适的、一致的、对许多应用程序有益的系统。这些应用程序的需求给我们提供了机会，这个机会在最初X协议设计时是没有的。

Alpha合成技术通过为每个像素值增加一个a值来混合图像，这个a值控制着对颜色的混合运算。Alpha合成提供了许多功能，最常见的是半透明操作，其对应的颜色计算公式是v = a*v1 + (1-a)*v2。通过半透明操作合成的图像看起来仿佛叠加在另一张图像上。
Alpha合成对近似反走样技术也有用。一个合适的函数和对（译者：待画物）结构和渲染原语顺序的约束能产生令人满意的渲染结果。
对3D应用程序来说，Alpah合成技术至关重要。因此，当前硬件一般都支持一些常见的OpenGL的Alpha合成功能。如果应用程序能访问硬件，那么合成过程的性能将大幅度提高。
许多方法可以显示具有alpha通道信息的图像数据。每像素值32位时，alpha通道信息通常由最高字节表示。每像素值16位时，alpha通道信息通常嵌入在某4比特内，但有时也可能存放在一个单独的8位图像内。
应用程序要最大限度利用加速功能，就必须知道相关硬件特性。这将极大地增加工具箱库的复杂性，工具箱库必须将渲染请求和可用的资源同时考虑在内。
Alpha合成在真彩色环境（32位色）下是很容易描述的。在伪彩色（24位色，译者：pseudoColor是否有更专业的名字？）环境下，像素值与颜色值之间没有线性关系，Alpha混合将更加困难。幸运的是，现代机器都能提供真彩色环境，仅在真彩色环境才提供alpha合成的方案是很诱人的。

反走样技术是信号处理在光栅化过程中的应用。它滤除了由没有精确定位的物体边界信息产生的高频噪声。从概念上说，反走样通过对图像实行基于屏幕分辨率的过采样和再采样来实现。
最直接的办法是先在内存中创建一个过采样版本的图像，再将其绘制到帧缓冲区或屏幕。但这将成倍的增加显存的使用量，成倍的降低渲染性能，所以须寻找一个低代价的折衷方案。
当显示一个简单的凸线图元（convex primitive）时，通过以上描述的简单的alpha合成操作可以获得正确的近似反走样效果。产生一个包含再采样过滤器输出信息的alpha通道，利用该通道信息可以将此图元合成到屏幕上。然而，当越来越多的图元被继续绘制时，这项工作将变得更困难，因为在合成操作中会失去各图元的边界信息。
OpenGL包含一系列更复杂的alpha操作，如果使用恰当，能减少在反走样近似过程中发生的错误。OpenGL中某些合适的操作将应用于新的渲染系统。
如上所说，alpha通道被设置成再采样过滤器的输出。现在大部分反走样系统简单地计算待画目标所覆盖的像素数目，并以此作为alpha值，对多边形的边界而言，系统沿着边界计算相应alpha值。更复杂的反走样系统使用2D过滤器的输出来设置alpha通道。在显示图像时，过滤器甚至考虑到了电子束的反映特征，使用此技术的反走样系统效果非常不错。
考虑到此alpha混合技术仅仅是近似准确的，同时这项复杂的技术在近阶段很可能存在性能问题，目前只考虑实现简单的覆盖模型（译者：上段提到的简单的反走样系统使用的方法）。以后会加入新的反走样机制。

当前的渲染系统使用一个16位整型坐标空间，这足以描述矩形。但画文本线和多边形时，此坐标系统是不精确的。当多边形被合成为较大的形状时，为了避免边界看起来不连续，采用子像素定位技术是必要的。
子像素定位允许应用程序更加精确地在屏幕上定位目标。使用核心协议渲染目标时，坐标值只能精确到1像素，这样误差最大可达1/2像素。这似乎不是很严重的问题，但误差累积所产生的视觉偏差是很显眼的。Scot Nelson更为细致地分析了此问题[Nel96]，并使用一个例子说明了在没有使用反走样技术前提下子像素定位所产生的改良效果。
我们会很自然地想到使用IEEE32位浮点数来表示坐标值。在16位X坐标空间内，24位尾数可以描述至少8位的子像素信息，应用程序也很容易管理此尾数。
然而，能保证被画目标的坐标值的不变性是再好不过的。当坐标值变得较大时，IEEE浮点数的部分子像素信息将被丢弃。在屏幕上移动窗口时，此问题尤为重要。虽然可以人为限定IEEE浮点数的精度以保证其值处于较小范围，但使用定点数能切地解决此问题。
下一问题是需使用多少位来描述子像素。对于大多数应用程序而言，4位足够了。但是8位能满足除某些非常特殊的情形外的所有应用。对使用较大坐标值空间的应用程序而言，在坐标值转换到X坐标空间的过程中仍需要对坐标值做近似处理，但如果还具有8位子像素信息，那足以应付在X坐标空间内裁减被画目标的工作。
基于以上原因，我们使用32位定点数来描述坐标值，其中8位未被使用。
不能通过X核心协议渲染未被定义的几何体。在PostScript解析器内，顶边和底边平行于水平线的梯形被称作水平梯形，可用它来绘制未被定义的几何体。LibArt是Gnome项目使用的渲染库，其"有序边列表"原语的作用如同水平梯形。
因此，引擎内至少要包含此种原语。与核心多边形请求不同的是，此请求还能一次绘制多个梯形。
是否实现PostScript风格的"路径"（译者：用于画任意线，在第2节中提到）仍是问题。如果实现，那将极大减少网络通信量，但同时会增加实现的复杂度。路径将包含线、三次样条和字元（译者：character elements不知可否译成字元，应该是指字符集中的字）。
把"路径"分解成上面描述的梯形，并使用一错误值变量来跟踪曲线的梯形分解过程。如果使此渲染机制对外可见，那么可以通过相对简单的方法来描述路径的像素化过程，在必要时还能在客户端精确地重现此像素化过程。
在最初设计X时，轮廓光栅还未被用于产生屏幕字体。当时仅有位图字体可用，且没有对放缩字体的需求。
所以最初的设计根本不能很好满足轮廓字体的要求。使用XLFD（注：其扩展支持放缩字体、字体子集和字形旋转）描述轮廓字体是困难的，或者可以说是不可能的。
字体命名和字体访问是有待解决的问题。加入一简单的机制就可以提供更多字体控制功能，并提供用其他方式来标识字体，而不仅仅是简单的字符串。另一问题是如何访问额外的字体信息，如两个字符间距表、字形名和更精确的字形信息。
流行的应用程序要求应用程序和X服务器都能访问最原始的字形信息。这允许应用程序在客户端增强服务器所提供的字体渲染功能。通过扩充X字体服务协议[Ful94]以包含这些额外信息即可解决问题。
关于核心协议的另一问题是如何访问字形信息。核心协议仅仅提供QueryFont请求，通过此请求可一次性获取一字体的所有字形信息。这允许客户端快速计算出字形子集的宽度，因为没必要再向服务器请求任何字形信息了。然而，这又要求字体中每个字形信息在请求到达时都是可获得的。对于放缩字体而言，这意味着整个字体必须被光栅化：对于大多数放缩技术而言，光栅化字形过程中可附带地生成X字形信息。
大多数应用程序在刚开始运行时会针对每个字体发出一个QueryFont请求，所以X服务器通常需光栅化应用程序使用的每个字体的每个字形。
另外，ListFontsWithInfo请求将返回字体的所有字形的边界信息。而计算边界信息又需要字体的全部信息集合。
设计新的字体信息请求是必要的。一个查询一列字形的请求外加一个字体查询函数，该函数可以在不光栅化字体的每个字形的前提下提供尽可能多的字体信息。
同样需要更好的渲染原语以提供字形和基线旋转功能、子像素定位功能和反走样功能。
在某种程度上或许能实现对字形轮廓的直接支持。实现难点是：轮廓字体格式的多样性，缺乏高质量Type1光栅（译者：光栅用于光栅化字体）和必需的渲染架构。

构建一个新的渲染系统需要一定时间，对构建过程中产生的反馈信息的利用是成功的关键。系统开发必须逐步进行，每一步建立在前一步的基础上。一些改进可能很快实现；由于资源限制，且精确的设计方案还未达成一致，另一些改进可能暂时被耽搁。

1. Alpha合成 许多应用程序需要此功能，但苦于没有经加速的客户端实现。此功能是绘制反走样图形的基础，可通过图形硬件大幅度提高其性能。
   #梯形原语
   将其实现放到服务器端会减少连接CPU和图形适配卡的总线上的命令数。
   
2. 路径 若将其实现放到服务器端将减少线路通信量（译者：X服务器与客户程序间），除非客户程序与服务器分别处于网络中两个节点，否则其性能不会有很大提升。
   
3. 字体访问 改进服务器和应用程序间的字体共享机制将更有利于对应用程序的管理和部署，这在复杂的网络环境下尤为明显。
   
4. 文本渲染 增加含反走样选项的轮廓字体显示功能的想法早已存在于"期望列表"内。
   每项功能必须首先用软件实现，然后针对某些硬件提供加速功能。如有可能，应利用已有的图形系统以避免重复的工作。特别是，对于OpenGL支持的芯片，OpenGL系统将会大大降低开发难度。
   

人们希望通过扩展X渲染模型的弥补来其缺陷。十三年过去了，未曾开发出一个可靠的扩展，而这种现状最近正在改变。新的图形工具箱能利用X核心协议提供高级渲染模型，它的出现为改进X渲染模型创造了条件。新的渲染模型正被设计，其目的是解决这些新的工具箱的性能问题和网络透明性问题，它必将大大增强X桌面环境的功能。

[Ado85] Adobe Systems Incorporated. PostScript Language Reference Manual. Addison Wesley, 1985.
[Ful94] Jim Fulton. The x font service protocol. X consortium standard, Network Computing Devices, Inc., 1994.
[Hob85] John D. Hobby. Digitized Brush Trajectories. PhD thesis, Stanford University, 1985. Also Stanford Report STAN-CS-85-1070.
[Nel96] Scott R. Nelson. Twelve characteristics of correct antialiased lines. Journal of Graphics Tools, 1(4):1-20, 1996.
[Pac89] Keith Packard. X nonrectangular window shape extension protocol. X consortium standard, MIT X Consortium, 1989.
[Pit67] M. L. V. Pitteway. Algorithm for drawing ellipses or hyperbolae with a digital plotter. The Computer Journal, 10(3):282-289, November 1967.
[SG92] Robert W. Scheifler and James Gettys. X Window System. Digital Press, third edition, 1992.