作xgl翻译的那位朋友请email联系我。 gogoliu (gtkdict@yahoo.com.cn)


原文链接：http://www.openbsd.org/papers/eurobsd2005/herrb-hopf.pdf
翻译人员：gogoliu

New Evolutions in the X Window System

X Window System的新进展

Abstract

概述

This paper presents an overview of recent and on-going evolutions in the X window system. First, the state of some features will be presented that are already available for several months in the X server, but not yet widely used in applications. Then some ongoing and future evolutions will be shown: on the short term, the new EXA acceleration framework and the new modularized build system. The last part will focus on a longer term project: the new Xgl server architecture, based on the OpenGL technology for both 2D and 3D acceleration.

本论文概述了X窗口系统最近发生的和正在进行的进展。首先，一些特征已经在X服务器中存在多月了，但还没被应用程序广泛使用。我们将先介绍这些特征的现状。然后我们将展示一些正在进行的和未来的进展：短期内完成的新的EXA加速框架和新的模块化构建系统。最后部分将把焦点集中于一个长期的的项目：新的Xgl服务器架构，基于OpenGL技术的2D和3D加速。

>>论文对 X 窗口系统内最近发生和正在发生的进展做一综述。首先，这里将要讨论的部分特性已经在 X 服务器中出现数月，但还没有广泛地被应用程序使用(注1)。

Introduction

介绍

The X window system celebrated its twentieth birthday last year. After some quick evolution in its early years, its development slowed down during the nineties, because the system had acquired a level of maturity that made it fit most of the needs of the users of graphical work stations. But after all this time, pushed by the competition with other systems (Mac OS X and MicrosoftWindows) the need for more advanced graphics features triggered new developments.

X窗口系统在去年庆祝了它的20岁生日。在最初几年取得了一些快速的进展之后，在90年代X窗口系统的开发工作减慢了，这是因为它已经达到一定的成熟度可以满足图形工作站用户的大部分需要。但这段时间过后，由其他系统（Mac OS X和微软Windows）之间的竞争所推动，对更先进的图形特征的需求触发了新的发展。

The first part of this paper is going to describe some of these features that are already available (and have been used) for a couple of years but not necessarily known by users of the X window system. A second part will address some on-going work that will be part of the X11R7 release: a new 2D acceleration architecture and the modularization of the source tree.

本论文的第一部分准备描述已经存在多年并且已经被采用的一些特征。这些特征X窗口系统的使用者不一定知道。第二部分将专注于一些正在进行并且将会成为X11R7发行一部分的工作：一个新的2D加速体系和源代码树的模块化。

In the third part, a complete redesign of the device dependent layer of the X server, based on OpenGL, will be presented. It will allow a better integration of accelerated 2D and 3D graphics and make it possible to take advantage of the powerful 3D acceleration engines available today even in low end graphics adapters.

第三部分将会介绍一个基于OpenGL的、经全新设计的X服务器设备相关层。它将允许加速的2D和3D图形更好的集成，并且可以利用如今即使是低端图像适配器都配备的强大3D加速引擎。

1 Already available new features

1.已经存在的新特征

This section aims to remind a couple of the already available features, used by some toolkits to get better user experience with X: client-side font rendering, including anti-aliasing using Xft2 and fontconfig as well as rendering improvements based on the Render and Damage extensions.

这部分的目的是回顾几个已经存在的特征。这些特征被一些工具包（toolkit）采用，并由此向X用户提供了更好的用户体验：客户端字体渲染，包括使用Xft2和fontconfig实现的抗锯齿效果，以及基于Render和Damage扩展的渲染改良。

It also presents the Composite extension and explains how the composite manager can be used to achieve various effects (transparency, shadows,...), taking advantage of the Render code already present in the existing X server.

本部分还会介绍Composite扩展，并且解释混合管理器是如何利用已经在现有的X服务器中存在的Render代码完成各种各样的效果（透明度，阴影等）的。

1.1 The Render extension

1.1 Render扩展

The original X protocol provides a display model based on traditional boolean operations between source and destination. The Render extension was designed to enhance this model by adding image compositing operations. Image compositing was formalized by T. Porter and T. Duff [6], and implemented in the Plan 9 window system by R. Pike and R. Cox. Keith Packard designed and implemented the Render extension in XFree86 [3]. Porter-Duff compositing adds a pixel opacity value called "alpha" to its color attributes. This opacity value can be used to represent two different effects: translucency and anti-aliasing. The effect of translucency is created when all pixels of an object have their color computed as a combination of the intrinsic color of the object and the existing background values. Anti-aliasing is achieved by taking into account partial occlusion of the background by the boundaries of an object.

原始的X协议提供了一个基于源和目的之间的传统布尔操作的显示模型。Render扩展被设计用来增强这个模型，它通过添加图像混合操作来达到目的。图像混合由T.Porter和T.Duff进行形式化，并且由R.Pike和R.cox在Plan9窗口系统中实现。Keith Packard设计和实现了XFree86中的Render扩展。Porter-Duff混合在一个象素的颜色属性中增加一个名为"alpha"的不透明值。这个不透明值可以用来表现两个不同的效果：半透明和抗锯齿。当一个物体所有象素的颜色由物体的内在颜色和背景颜色组合计算而成，半透明效果就产生了。抗锯齿由计算一个物体边缘对背景的部分遮挡而成。

The Render extension implements new primitives for the display of images and polygons, as well as the basis for a new font rendering system that takes advantage of the image compositing features to render anti-aliased text.

Render扩展为显示图像和多边形实现了新的原语，并且为新的字体渲染系统利用了图像混合特征来渲染抗锯齿文字提供了基础。

Some of the core X applications have been extended to be able to use the X render extension: for instance xclock in analog mode now draws anti-aliased and translucent clock hands.

一些核心X应用程序被扩展为可以使用X渲染扩展：例如现在xclock在模拟模式下会绘制抗锯齿和半透明的时钟指针。

The Render extension was developed initially in XFree86 (now in X.org). It has been adopted by many commercial X providers too and thus can be assumed as a standard for modern applications.

Render扩展最初在XFree86（现在是X.org）上面开发。现在它已经被许多商业X提供者采纳，因此现代应用程序可以假设它是一个标准扩展。

1.2 Client-side font rendering

1.2 客户端字体渲染

When X was originally designed, more than twenty years ago, it was decided that
text display would be done by the X server. In the traditional X world, fonts are a
server-side resource and applications depend on the fonts available in the server.

20多年前，当X初始设计时，它决定文字显示由X服务器完成。传统X的世界里，字体是服务器端的资源，而应用程序只能使用服务器中存在的字体。

This approach had the advantage of limiting the amount of data that text-based
applications have to send to the server, but it also caused lots of frustration among
application developers. PDF or Postscript viewers for instance need to be able to
render fonts that are embedded in the document they are displaying.

这种处理方式有自己的优点：可以限制文字应用程序发送到服务器的数据总量，但这也会给应用程序开发者带来许多阻挠。举个例子，PDF或者Postscript查看器需要能够渲染嵌入在它们正在显示的文档中的字体。

Moreover applications need access to more than just bitmaps in the fonts specifications
for precise rendering. Attempts to extend the server-based font rendering
model have all failed to solve all problems.

此外，为了更精确地渲染，应用程序需要得到比字体规范所规定的位图文字更多的字体。扩展服务器端字体渲染模型的尝试都不能解决全部问题。

So, together with the introduction of Render, a radical decision has been taken
to move font rendering from the server to client applications. To achieve this, a
new text-rendering library has been designed; it is now at its second revision: Xft2.
A companion library, fontconfig provides support to all font naming, installation
and caching issues.

所以，在引入Render的同时，也下了一个激进的决定：把字体渲染从服务器转移到客户应用程序。为了达到这个目的，一个新的文字渲染库被设计出来；现在它处于它的第二个版本修正：Xft2。一个伴随的库：fontconfig为字体命名、安装和缓存提供了支持。

Fontconfig can, by the way, be used on a broader spectrum of applications
than just X. It could be used by TEX like publishing applications, printer drivers
and so on. Fontconfig uses XML formatted configuration files, located in the
/etc/fonts directory.

附带地，Fontconfig可以被比X更大范围内的应用程序所使用。它可以被类TEX的出版应用程序、打印机驱动等应用程序所使用。Fontconfig使用XML格式的配置文件，这些文件在/etc/fonts目录下。

Xft2 is based on the Freetype library. It can render several font formats:
the traditional bitmap-based PCF format from the legacy server-side font system,
Postscript Type 1 and True Type fonts.

Xft2基于Freetype库。Freetype库可以渲染几个字体格式：来自服务器端字体系统的传统的基于位图的PCF格式，Postscript Type 1和TrueType字体。

Xft2 also provides some enhancements in the font encoding management,
among others it is possible to use UTF-8 encoded text directly with Xft2.

Xft2也在字体编码管理方面提供了一些增强，其中之一就是可以在Xft2中直接使用UTF-8编码的文字。

Measurements have shown that the new client-side font rendering scheme has
little to no impact on the overall performance. In many cases, it reduces the number
of round-trips between the application and the server and thus even greatly
improves application startup times.

测量显示新的客户端字体渲染模式对整体性能只有有少许甚至没有影响。在很多情况下，它减少了应用程序和服务器之间的数据包往返次数，因此大大地改善了应用程序启动时间。

Like Render, the Xft and fontconfig libraries have been embraced by more
than XFree86 and X.Org. They are now the standard way of displaying text for X
toolkits and applications. The legacy server-side mechanism is obsolete and should
not be used by new developments anymore.

如Render那样，Xft和fontconfig库已经被包括XFree86和X.Org在内的多个X实现包含。它们现在是X工具包和应用程序显示文字的标准方式。陈旧的服务器端机制被舍弃，而且不应该在新的开发过程中使用。

1.3 Composite, Damage, Xfixes extensions and the composite manager

1.3 Composite, Damage, Xfixes扩展和混合管理器

To take the full advantage of the image compositing model provided by the X
render extension, for example to provide translucent windows or to have a window
manager add drop shadows to the windows, there are some bits missing. In the
traditional X model, each application draws its window independently and doesn't
take care of underlying or overlaying windows.

为了从X Render扩展所提供的图像混合模型中获得全部好处，例如提供半透明窗口或让一个窗口管理器为窗口添加阴影，这还缺少一些东西。在传统的X模型中，每一个应用程序独立地绘制它自己的窗口，并且不会理睬下层或上层的窗口。

To be able to implement those eye candies, applications should be redirected
to use off-screen windows, and a specific application, the composite manager, will
work with the window manager and the new Composite extension to compute the
screen's contents, doing compositing operations to produce translucency, shadows
and anti-aliased polygons and texts.

为了能够实现那些炫目的效果(eye candies)，应用程序应该改为使用离屏窗口，另外一个特殊的应用程序：混合管理器将和窗口管理器一起工作，新的Composite扩展用于计算屏幕的内容，完成混合操作来产生半透明、阴影和抗锯齿多边形和文字。

Figure 1: Composite manager principle: traditional direct on-screen drawing on
the left, vs off-screen drawing & compositing on the right.

图1：混合管理器原理：传统的直接写屏（左边）与离屏绘图然后混合（右边）的对比

To make this work, this application needs a bit more information than before
about what is happening on the screen, and it needs this information in an efficient
manner. This is the goal of the the Damage extension: it provides an efficient
way to notify an application of damage done to a region of the screen by another
application.

要让这运作起来，应用程序需要比前面所列更多一点的信息－－屏幕发生了什么，并且它需要这些信息以有效的方式给出。这是Damage扩展的意义所在：它提供一个有效的途径来通知一个应用程序另一个应用程序对屏幕某个区域的破坏。

The Xfixes extension provides a general framework to extend the X protocol
in order to work around some limitations in the core protocol. It currently contains
five fixes. The more important ones allow better manipulation of the application
cursor and export the region objects from the server to the clients.

为了解决X核心协议的一些限制，Xfixes扩展提供了一个通用的框架来扩展X协议。当前，它包含5个修正(fix)。其中比较重要的修正就是允许更好地操纵应用程序指针以及从服务器传输区域对象到客户应用程序。

xcompmgr is a sample composite manager that can be used with any existing
window manager to provide some eye candy. Figure 2 shows the default OpenBSD
desktop enhanced with xcompmgr and anti-aliased fonts in xterm and firefox.

xcompmgr是一个试验混合管理器，它可以和任何现存的窗口管理器一起运作提供一些炫目的效果。图2显示了使用xcompmgr后的默认的OpenBSD桌面，以及xterm和firefox中的抗锯齿字体。

Figure 2: Adding eye-candy to the default OpenBSD desktop

图2：添加了炫目效果后的默认OpenBSD桌面

KDE provides its own composite manager, kompmgr, while some window
managers (Luminocity for instance) are integrating this functionality.

KDE提供了它自己的混合管理器kompmgr，而一些窗口管理器（例如Luminocity）则集成了这些功能。

1.4 Cairo

1.4 Cairo

Another important evolution in graphical user interfaces is the growth of vectorbased
graphics, as opposed to existing bitmap-based graphics. Vectors offer a better
representation of screen contents, independent of the actual resolution, allow
producing a perfect-looking printed version of an on-screen document, use less
space for storage, and provide a better base for anti-aliased graphics.

图形用户界面的另一个重要的进展是不断增加的基于矢量的图形，这与现存的基于位图的图形是相对的。矢量为屏幕内容提供了一个更好的呈现，它独立于实际的分辨率，允许产生一个更完美的屏幕文档的打印版本，使用更小的存储空间，并且为抗锯齿图形提供一个更好的基础。

With the introduction of the Render extension, X now has the ability of producing
high-quality graphics based on vector representation.

引入Render扩展的同时，X现在拥有了产生基于矢量绘图的高质量图形的能力。

Cairo [1] is a library that implements vector based graphics with support for multiple
output devices. Existing back-ends include X with the Render extension, and
image buffers [4]. Experimental drivers include OpenGL (through the glitz library)
and PDF files.

Cairo [1]是一个实现基于矢量的图形并且支持多个输出设备的库。现在的后端包括拥有Render扩展的X和图像缓存 [4]。试验的驱动包括OpenGL（通过glitz库）和PDF文件。

The Gtk+ toolkit as well as some existing applications already started to base
most of their graphics on the Cairo library.

Gtk+工具包和一些现存的应用程序已经开始把它们的图形的大部分构建在Cairo库之上了。

The OpenGL back-end offers some interesting features: on systems with accelerated
OpenGL it provides the toolkits and application with a way to do accelerated
2D graphics that almost completely bypass the X libraries and server.
However, this doesn't provide a solution for the global desktop compositing acceleration
mentioned above.

OpenGL后端提供了一些有趣的特性：在有OpenGL加速的系统中，它为工具包和应用程序提供了一个加速2D图形的途径，这几乎完全绕过了X库和服务器。但是，这没有为上面提及的全局桌面混合加速提供一个解决方案。

2 Ongoing work

2 正在进行的工作

The current Xserver is divided in an architecture independent (DIX) and an architecture
dependent (DDX) layer, which in turn loads the relevant hardware driver for
rendering into the framebuffer. In order to accelerate drawing operations, the hardware
drivers offer functions that implement certain operations using the graphics
hardware. The traditional interface for this is the Xserver Acceleration Architecture
(XAA), which mainly focuses on accelerating core X protocol requests.

当前的X服务器被分为一个体系结构无关层和一个体系结构相关层。后者依次装载相应的硬件驱动来渲染到帧缓冲。为了加速绘图操纵，硬件驱动提供了几个用硬件完成的操作的函数。传统的，此界面是X服务器加速体系（XAA），XAA主要集中在加速核心X协议请求。

In contrast to the features described in the previous section most ongoing and
future developments focus on the Xserver framework. These changes will not affect
the programmer's API, as e.g. the Render and Composite extensions did, so all
applications can immediately benefit from their implementation.

与前面部分描述的特征形成对比，大部分正在进行和未来的开发集中于X服务器架构。这些改变将不会影响到程序员的API，例如Render和Composite扩展所提供的功能，所以所有的应用程序可以从它们的实现中获益。

This section describes on-going work, which is available in the X11R6.9 /
X11R7 release: the new 2D acceleration architecture EXA and the modularization
effort. The EXA architecture is aimed at replacing XAA in drivers, focusing
on accelerating primitives used by modern applications based on the render extension.
The modularization effort will be described from an architectural point of
view.

这部分描述了正在进行的工作，它们将会出现在X11R6.9/X11R7发布中：新的2D加速体系结构EXA和模块化成果。EXA体系结构的目标是在替代XAA驱动，它将集中在加速基于Render扩展的现代应用程序所使用的元语。模块化的成果将会从一个体系结构的视角进行描述。

2.1 A new acceleration architecture for Render: EXA

2.1 为Render而作的新加速体系：EXA

Without composite manager, the performance of the Render extension is decent on
reasonably recent hardware, that doesn't even deserve the "fast" qualifier. However,
most of of Render computations are done on the main CPU and take little
advantage of GPU acceleration. Render takes advantage of MMX or SSE instructions
when they're available, and there have been some work done to add basic
hardware acceleration for Render in the radeon driver.

没有混合管理器，Render扩展的性能在新近的硬件中是可接受的，但不能用"快速"来形容。但是，大部分的Render计算操作都是在CPU中完成，很少利用GPU加速器。当MMX或SSE指令集可用时，Render将会利用它们，并且在radeon驱动中已经做了一些工作来为Render增加基本的硬件加速。

When the composite manager is involved, things get worse, performance-wise.
Even today's "fast" hardware can feel slow with compositing enabled. It is thus
mandatory to rework the acceleration framework so that Render and Composite
can be accelerated much better.

当有了混合管理器后，性能变差了。当开启混合后，即使是今天快速的硬件也会感到缓慢。因此必须重写加速架构以便Render和Composite可以得到更好的加速。

The currently used acceleration architecture in Xorg (XAA) is unsuitable for
modern desktop usage. As a result of heavily using the card's 2D engine to accelerate
mostly rarely used operations (like pattern fills and Bresenham lines) it invalidates
any backing store that the X server might have on a region. Furthermore
accelerating the Render extension using XAA is rather complicated and severely
limited by its memory manager.

Xorg中现行的加速体系XAA是不适合现代桌面使用的。作为很大程度上使用显卡的2D引擎来加速大部分很少使用到的操作（象图案(pattern)填充和Bresenham线）的结果，它使X服务器可能在一个区域拥有的后备缓存无效。此外，使用XAA加速Render扩展是相当复杂的，而XAA的内存管理导致加速非常有限。

EXA (for EXcellent Architecture or Ex-kaa aXeleration Architecture or whatever)
aims to extend the life of the venerable XFree86 video drivers by introducing
hooks that they can implement to more efficiently accelerate the X Render extension:
solid fills, blits within screen memory and to and from system memory, and
Porter-Duff compositing and transform operations. It has been implemented by
Zack Rusin in X.org.

EXA（代表卓越的系统结构或脱胎于kaa的加速体系或者无论什么）的目标是延长古老的XFree86视频驱动的生命，它通过引入可以更有效地执行加速X Render扩展的钩子(hook)来达成目标：实体(solid)填充，在屏幕内存内部和屏幕内存与系统内存之间进行位块传递(blit)，以及Porter-Duff混合和变换操作。EXA由X.org的Zack Rusin实现。

A couple of existing drivers have already been converted to use the new
EXA acceleration framework if requested: the i810 driver for Intel graphics card
adapters, the radeon driver for ATI Radeon cards, the sis driver and the i128 drivers.

几个现存的驱动已经经过修改，当用户要求时它们将可使用这个新的EXA体系架构，这几个驱动包括了Intel图形卡的i810驱动、ATI Radeon卡的radeon驱动、sis驱动和i128驱动。

2.2 Source tree modularization

2.2 源代码树模块化

One of the big tasks in the lastest X release has been a complete rework of the X
build system. The existing source tree, built using the imake build system, was
considered as a big monolithic thing in which most developers found themselves
uncomfortable. The need for global releases, updating all drivers at once every six
month or so doesn't really fit the market of graphics cards that can produce new
models more often than that timeframe.

最近的X发布的一项重要任务就是完全重写X构建系统。现存的代码树使用imake构建系统进行构建。这种情况下代码树被看作一个庞大的个体，许多开发者对此觉得不舒服。整体发布需要每六个月同时更新所有的驱动，这不完全符合图形卡市场的发展，图形卡制造出新的型号的周期可以比这个短。

Based on the experiences of other software projects, it was decided to switch to
a more modular organization of the project, with more or less independent components
[8]. This new organization will allow drivers maintainers (or others) to make
independent releases, whenever they are needed.

基于其他软件项目的经验，开发者决定把该项目的组织变得更模块化，伴随或多或少的独立组件[8]。新的组织将允许驱动维护者（或其他人）在有需要时进行独立的发布。

It was decided that the best tools to manage the build of this new modularized
source tree are the GNU auto-tools. They have an existing large user and developer
base, and thus feel easier to use by the majority of developers. Being maintained
outside of the X.Org project is supposed to lower the maintenance burden on the X
developers which are now free to concentrate on their code.

被认为管理这个新模块化代码树的构建的最好的工具是GNU auto-tools。GNU auto-tools有很多的现存用户和开发者基础，并且大多数开发者觉得它很容易使用。在X.org项目外维护被认为可以降低X开发者的维护负担，因为现在他们可以独立自主地集中于他们的代码了。

The existing source tree has been split in several components, and each of them
is composed of independent packages. The main components are:

现存的代码树被分为几个组件，并且他们的每一个都被组成独立的软件包。主要的组件有：

• xproto which holds all the header files describing the actual X protocol and

extensions. There is one package for the core X protocol and one package
per X extension (Shape, MIT-SHM, Render, etc.),

• libs which holds all the libraries, one package per library (X11, Xext, Xrender,

etc.),

• data which holds several data files (bitmaps and icons, XKB data files, X

cursors),

• apps which holds the sample applications provided by X.Org (twm, xcalc,

xedit, xlogo, xman, xwd, etc),

• xserver which provides the different X servers (Xorg, Xnest, Xprint, Xvfb),
• drivers which provides the graphics cards drivers, each one in an independent

package,

• fonts which provides several fonts packages,
• doc for the existing documentation that doesn't fit a a specific package,
• utils various utilities that help the modular infrastructure, including an autotoolized

version of imake, for use with third party applications that still depend on it.

• xproto，它包含所有描述实际X协议和扩展的头文件。核心X协议有一个软件包，而每一个X扩展（Shape, MIT-SHM, Render等）都有各自的软件包。
• libs，它包含所有的库，每个库（X11, Xext, Xrender等）一个软件包。
• data，它包含若干个数据文件（位图和图标，XKB数据文件，X光标）
• apps，它包含X.org提供的示例应用程序（twm, xcale, xedit, xlogo, xman, xwd等等）
• xserver，它提供各种X服务器（Xorg, Xnest, Xprint, Xvfb）
• drivers，它提供图形卡驱动，每一个在一个独立的软件包中
• fonts，它提供若干个字体软件包
• doc，包含那些不符合一个具体软件包的文档
• utils，包含各种各样对模块化基础设施有用的实用程序，包括一个autotool版本的imake，这为仍然依赖于imake的第三方应用程序所用。

Dependencies and configuration of the new packages is heavily based on the
pkgconfig2 tool.

新软件包的依赖关系和配置基于pkgconfig2工具。

To make the transition smoother, X11R6.9 and X11R7 share the same source
base, and as far as possible produce the same set of binaries. X11R6.9 is the last
version of the monolithic tree, while X11R7 is the first version based on the new
modular tree. Both releases should be equivalent feature-wise.

为了让转换过程更平滑，X11R6.9和X11R7共享了相同的代码基库，并且尽可能地生成相同的二进制文件集。X11R6.9是单体树的最后一个版本，而X11R7是基于新的模块化树的第一个版本。两个发布在功能上都是一致的。

Future work will be done in the modularized tree only. Only patches and bug
fixes will be done in the X11R6.9 brah.

未来的工作将只在模块化树中进行。X11R6.9分支将只会进行修补和除错工作。

3 The future: Xgl

3 未来：Xgl

This last section will present the ideas, the rationale and the work already done
to move to a new X server rendering model, based on OpenGL and glitz. This
Xserver, called Xgl3, is mainly developed by David Reveman. Currently it has to
be run on top of a regular Xserver, comparable to Xnest, but first steps have been
made to use Embedded OpenGL (EGL) extensions to make it run stand-alone [7].

最后一章将讨论基于OpenGL和glitz的新的X渲染模型的想法、基本原理和已经做的工作。
这个称为Xgl的X服务器主要由David Reveman开发。目前，它需要在运行在正规的X服务器上，
(这方面和Xnest很像), 但是第一步的工作已近展开：使用嵌入式OpenGL(EGL)扩展使得它
能独立运行.

3.1 Why use OpenGL

3.1 为什么使用OpenGL

When looking at the current state of the Xserver architecture, several shortcomings
are getting obvious, which we will analyze in detail now:

如果我们察看现在的X服务器体系结构的状况，我们会发现一些很明显的缺点：

• XAA does not match current rendering use and is difficult to extend,
• the X server is a mix of high level code (window management etc.) and low

level code (drivers),

• there are little to no ideas how to support modern graphics hardware features

like pixel shaders,

• the driver API is used by Xserver only,
• the driver API is basically 2D only,
• drivers are difficult to maintain outside of main development tree,
• future graphics hardware won't have a 2D acceleration core any more.

• XAA与当前的渲染技术的使用并不匹配，并且难以扩展。
• X服务器中高层代码(窗口管理等)和低层代码(设备驱动)相互混杂。
• 对如何支持现代图形硬件的特性(如pixel shaders)难以有好的想法。
• 设备驱动API只能被X server使用。
• 设备驱动API基本上只支持2D
• 设备驱动在主开发树外难以维护。
• 将来的图形设备不会再有2D加速芯片

The current acceleration architecture, XAA, has pretty much reached the end
of its productive life, as it is difficult to implement and maintain, and modern applications
don't use many core X requests for rendering any more. Many new features
like the Render extension have to be implemented and tested for each driver, which
is a tedious and troublesome work.

当前的加速体系，XAA，已近快到了它生命的尽头，难以实现和维护，并且
现代的应用程序不再使用许多核心的X请求来做渲染。
许多新的特性比如渲染扩展需要对每个驱动程序加以实现和测试，这是
单调和麻烦的工作。


EXA is one alternative that has already been discussed in the previous section,
but it still has the disadvantage that it keeps the driver code inside the Xserver,
while it would be a worthy goal to have a real driver abstraction layer.
Both acceleration architectures are 2D only APIs, that are used by the Xserver
alone and not by other programs. APIs that are used by only a small number of
programs tend to be less stable and flexible than APIs used by many programs.
While using 2D for a windowing system makes basically sense, there are several
ideas how 3D user interfaces could enhance productivity in the long-term future,
for instance with the project Looking Glass[4].

EXA是一个候选者，并在之前做了讨论。但是它依旧有将驱动代码放在X服务器中的缺点；拥有一个实际上的驱动程序抽象
层是一个很有价值的目标。再者，加速体系只是2D的API，只被X服务器使用。只被少数程序使用的API在稳定性
上是比不上被许多程序使用的API的。虽然说在窗口系统中使用2D是有道理的，但是
一些想法说明从长远来看使用3D可以提高效率，比如Looking Glass项目。


On the X.Org developer's conference 2005 all attendants agreed that using the
industry standard 3D graphics interface OpenGL is a worthy investigation for a
driver abstraction layer. David Reveman showed an early version of his Xgl prototype,
which since then has matured and supports OpenGL based implementations
of most important drawing operations in the Xserver. Additional features have been
contributed by the community, for instance Xegl (Dave Airlie, Adam Jackson, John
Smirl) and XVideo (Matthias Hopf).

在X.org的2005年开发者会议上，与会者同意使用工业标准的3D图形接口OpenGL
作为驱动抽象层是值得投资的。David Reveman展示了Xgl初版的原型，从那以后
Xgl变得更加的成熟并且基于OpenGL实现了大部分的Xserver画图操作。社区贡献
了一些附加的特性，比如Xegl(Dave Airlie, Adam Jackson, John Smirl)和
XVideo (Matthias Hopf).

Basically, Xgl has shown even in its early state, that using OpenGL for the
drawing operations needed for an Xserver is a viable option, which additionally allows
for more advanced compositing operations as it will be shown in Subsect. 3.3.
It also gives easy access to modern features of graphics hardware like vertex and
pixel shaders, and as the API continues to evolve we will see future capabilites
exposed as well. Furthermore, hardware vendors use a lot more transistors and
invest more in the design for the 3D core, so it is very likely to be faster than the
2D acceleration core.


The most important advantage is, however, that finally the Xserver has got rid
of its hardware drivers, which can now be maintained outside the Xserver tree. E.g.
Render is accelerated on every graphics hardware with OpenGL drivers, not just
on the ones that actually implement the required acceleration interface. Having
drivers removed from the Xserver core is especially important with future graphics
hardware, which won't have 2D acceleration any more, and for which only closedsource
OpenGL drivers exist. While vendors can (and do) implement their 2D
drivers themselves as well, having a stable interface abstraction using a standard
API will certainly improve the driver quality.

3.2 The architecture of Xgl

3.2 Xgl的架构

Figure 3 shows an overview over the Xgl architecture. At the moment Xgl is one
additional DDX in the kdrive Xserver, which is an experimental Xserver mostly
written by Keith Packard. After the Xorg modularization is finished, Xgl will
slowly be integrated into the main stream Xorg server as an additional DDX as
well.


OpenGL is still a relatively low-level API, so it made sense to create an
abstraction layer that covers the most common graphics operations. As many X operations
are pixmap oriented, texture handling is of particular importance.


Before working on Xgl David Reveman implemented an OpenGL based backend
for Cairo [2]. The semantic of this backend, named glitz, closely resembles the
Render protocol, and thus was the perfect abstraction layer for Xgl. Basically, glitz
is an OpenGL image compositing library, which provides Porter-Duff compositing
of images with implicit mask generation for geometric primitives. This includes,
but is not limited to, alpha blending and affine transformations, and it has support
for additional features like convolution filters and color gradients, which are not
needed for Cairo. It also abstracts general texture use and the different sorts of
OpenGL buffers.


There are no software fallbacks in glitz, if the hardware isn't capable of implementing
a certain operation, glitz will just report the failure.
Certain operations of glitz require modern OpenGL features, for instance convolution
filters or color space conversion and resampling for YUV textures both
need pixel shaders. If the hardware isn't capable of these operations, a general
software fallback inside glitz would result in poor performance, while the upper
layer can easily implement this particular feature (e.g. color conversion) in software
in an optimized way.


Applications that want to use OpenGL for drawing have to share the drawing
space with the Xserver. As currently there is no way to share textures or framebuffers
between applications, they currently have to use indirect rendering, i.e. the
Xserver is doing the actual OpenGL calls it gets via the GLX protocol from the
application. On one hand, this can be significantly slower for applications doing a
lot of memory transfer (video textures or geometry with high primitive count), on
the other hand Xgl is now one of the few X servers capable of doing hardware accelerated
indirect rendering, for example for running OpenGL programs remotely,
which isn't implemented in Xorg yet.

3.3 Composite managers using OpenGL

3.3 使用OpenGL的混合管理器

As already described in Subsect. 1.3, all windows are rendered to off-screen
pixmaps when the Composite extension is active. In the OpenGL case, this means
the Xserver must render to an off-screen framebuffer, which can be provided by
either the pBuffer or the more modern Frame Buffer Object (FBO) extension. Unfortunately,
pBuffers are not yet widely supported, and implementation of FBOs is
even less common and unstable. In these cases Xgl has to do all rendering to client
windows in software and download the window contents to textures afterwards,
which surprisingly is still quite usable.

The pixmaps with the window contents can afterwards be composed using
the Composite extension. An alternative to this is to use GLX to do the
compositing with indirect OpenGL rendering. For this the composite manager
has to be able to bind off-screen pixmaps to textures, which is done with the
GLX_MESA_render_texture extension from Xgl. Figure 4 provides the complete
architectural overview over a session using an OpenGL based composite manager.


With this type of composite manager windows can be arbitrarily placed in 3D,
which leads to pretty exciting rendering possibilities (see Fig. 5). Note that the
pixmaps stay on the graphics hardware all the time, and only the geometry to be
rendered has to be transfered from the composite manager to Xgl.

3.4 Caveats and pitfalls

3.4 告诫和陷阱

Currently Xgl is working best when run on top of a regular Xserver, comparable to
Xnest. OpenGL provides neither facilities for creating a displayable framebuffer,
nor for changing display modes. Both issues are addressed by the experimental
EGL_MESA_screen_surface extension, which uses the buffer management
ideas incorporated in Embedded OpenGL (EGL). The extension is close to being
submitted to the Embedded OpenGL ARB for review. Right now there exists an
early implementation in Mesa, named Xegl 5, for the R100 and R200 based Radeon
chips from ATI, but several hardware vendors want to provide all extensions needed
for Xgl to run in the future.


However, for full functionality, extensions for creating a hardware mouse
pointer, getting monitor information, and setting drivers for different output plugs
are needed as well. These extensions are not specified yet.


One major drawback of Xgl right now is that applications cannot do direct
OpenGL rendering at all. For this an extension for sharing textures between address
spaces is needed, as the application, Xgl, and the composite manager are all
running in different address spaces. This is the subject of current discussions, but
nothing is specified yet.


During the implementation phase of Xgl, several pitfalls have been encountered,
but for most of them a reasonable solution has been found. First, with many
OpenGL drivers one can easily get namespace collisions, as Xgl needs to be linked
against a software rendering Mesa library for fallback and GLX handling as well as
against the current OpenGL library on the host system. This can be solved by loading
the OpenGL backend dynamically, which also allows for the Xegl backend to
be loaded upon availability automatically. Then, frame buffer objects have turned
out to be pretty unstable for many operations, so the code path using pBuffers will
stay around longer than anticipated.


One source for major headaches in the open source community is of course
the lack of open source drivers for modern graphics hardware, which are often
only covered by binary only OpenGL drivers. One notable exception here is Intel,
which has committed itself to providing open source drivers for future chips as
well. Currently, their drivers are not yet equivalent to their competitors with respect
to implemented features, but they are advancing steadily.

3.5 Implementation on BSD systems

3.5 BSD系统上面的实现

Xgl currently runs on any system providing OpenGL, but it is unusable without
hardware acceleration (i.e. without DRI support).


For the longer term, Xegl needs a console driver that provides a graphical mode
with EGL drivers. The first implementations will be done on the Linux framebuffer
driver. NetBSD and OpenBSD share the wscons console driver, on which some
level of support for graphical console is already available. FreeBSD has his own
console driver, syscons, that doesn't provides a graphical mode yet, as far as we
know.


The integration of these graphical modes with hardware OpenGL acceleration
(and DRI) is required to provide an EGL capable console with support for the
necessary hardware setup extensions.


BSD developers will have to work with Linux DRI developers to make sure
that the direct rendering infrastructure is kept in sync with the Linux DRI with
respect to features like the proposed EGL extensions. A good way to help here
would be to discuss the new extensions on the dri and dri-egl mailing lists so
that no requirements are missed.


In the short term, with these extensions not completely specified, some more
low-level hardware access might be necessary inside the Xserver, and BSD and
X.org should work closely together as soon as more development efforts are concentrated
upon Xegl.

Conclusion

After a couple of years of relative stagnation in the world of the X window system,
development has resumed, with the goal of providing rich enough functionalities
for desktop environments which want to provide eye-candy on par with other Desktop
OSs. The wide availability of cheap OpenGL-capable graphics cards makes
such a new project realistic, although the lack of support for open source systems
by most of the hardware vendors darkens the bright sky of this new technology.

结论

在将近12年的停滞之后，X window系统的发展已经复苏，它的目标是为桌面环境
提供足够丰富的功能，以便它能够提供与其他桌面环境一样眩目的东西(eye-candy).
广泛可用并廉价的提供了OpenGL特性的图形卡使得这样的新工程有了现实意义，虽然
在另一方面，大部分硬件厂商对开源系统支持的缺乏给这一新技术的明亮的天空
抹上了一丝黑色。

References

参考文档

[1] S. Nickell. Design fu: Xshots. http://www.gnome.org/~seth/blog/xshots, March 2005.
[2] P. Nilsson and D. Reveman. Glitz: Hardware Accelerated Image Compositing Using Opengl. In Usenix 2004 Annual Technical Conference, Freenix Track, pages 29-40, June 2004.
[3] K. Packard. Design and Implementation of the X Rendering Extension. In Usenix Technical Conference, Boston, June 2001.
[4] K. Packard. Cairo status. http://keithp.com/keithp/talks/cairo-exdc2005/, June 2005. European X.Org developpers Meeting, Karlsruhe.
[5] K. Packard. X Status Report. http://keithp.com/~keithp/talks/x-rearch-lca2005, April 2005. Linux.conf.au.
[6] T. Porter and T. Duff. Compositing Digital Images. Computer Graphics, 18(3):253-259, July 1984.
[7] J. Smirl. The state of linux graphics. http://www.freedesktop.org/~jonsmirl/graphics.html, September 2005.
[8] D. Stone. X.org modularization. "Where to from here?". http://people.freedesktop.org/daniels/exdctalk/, June 2005. European X.Org developpers Meeting, Karlsruhe.

注1：打个岔 :) 广泛地被应用程序使用，被应用程序广泛使用，似乎有点微妙的差别呢。这 wiki 地 log 和 diff 似乎不支持我们的编码啊。

changelog: 重新启动改为复苏。