原文链接：http://keithp.com/~keithp/talks/xarch_ols2004/ 翻译人员：gogoliu The (Re)Architecture of the X Window System X 窗口系统的崭新架构 James Gettys jim.gettys@hp.com Keith Packard keithp@keithp.com HP Cambridge Research Laboratory HP剑桥研究实验室 Abstract 概论 The X Window System, Version 11, is the standard window system on Linux and UNIX systems. X11, designed in 1987, was ``state of the art'' at that time. From its inception, X has been a network transparent window system in which X client applications can run on any machine in a network using an X server running on any display. While there have been some significant extensions to X over its history (e.g. OpenGL support), X's design lay fallow over much of the 1990's. With the increasing interest in open source systems, it was no longer sufficient for modern applications and a significant overhaul is now well underway. This paper describes revisions to the architecture of the window system used in a growing fraction of desktops and embedded systems 11版本的X窗口系统是Linux和UNIX系统的标准窗口系统。在1987年设计的X11，在当时是最先进的。一开始它就是一个网络透明的窗口系统，X客户应用程序可以运行在网络中的任意一台机器上，而使用运行在任意有显示设备的机器上的X服务器进行显示。由于X的历史进程中有一些很重大的扩展（例如OpenGL支持），X的设计原则在90年代已经被超越了。来自开源系统爱好者们的持续关注，X已经不能适应现代应用程序了，一次重大的检修正在进行中。本论文描述了对已经在桌面系统和嵌入式系统中使用的X窗口系统架构的修正。 Introduction 一、介绍 While part of this work on the X window system [SG92] is ``good citizenship'' required by open source, some of the architectural problems solved ease the ability of open source applications to print their results, and some of the techniques developed are believed to be in advance of the commercial computer industry. The challenges being faced include: # X's fundamentally flawed font architecture made it difficult to implement good WYSIWYG systems # Inadequate 2D graphics, which had always been intended to be augmented and/or replaced # Developers are loathe to adopt any new technology that limits the distribution of their applications # Legal requirements for accessibility for screen magnifiers are difficult to implement # Users desire modern user interface eye candy, which sport translucent graphics and windows, drop shadows, etc. # Full integration of applications into 3 D environments # Collaborative shared use of X (e.g. multiple simultaneous use of projector walls or other shared applications) 某些开发出来的技术相信是超过商业计算机工业水平的。这些工作要面对的挑战包括： * X的基础的却有缺陷的字体架构使其很难实现良好的所见即所得(WYSIWYG)系统 * 欠缺的2D图形，将会被增强或者代替 * 开发人员讨厌采纳任何会限制他们的应用程序分发的新技术 * 难以实现屏幕放大镜这一辅助功能的正当要求 * 用户渴望炫目的现代用户界面，它应该支持半透明图形和窗口、阴影等 * 完整的集成应用程序到3D环境 * 协作共享使用X（例如，同时多个使用投影墙或其它共享的应用程序） While some of this work has been published elsewhere, there has never been any overview paper describing this work as an integrated whole, and the compositing manager work described below is novel as of fall 2003. This work represents a long term effort that started in 1999, and will continue for several years more. 虽然某些工作已经在其它文章中发表，但是至今为止没有任何一篇概括性的论文对这些工作进行整体的描述。而且下面提到的混合管理器在2003年秋季时还是非常新颖的。这些工作表现了1999年来的长期努力，而且将会持续数年。 Text and Graphics 二、文字和图形 X's obsolete 2D bit-blit based text and graphics system problems were most urgent. The development of the Gnome and KDE GUI environments in the period 1997-2000 had shown X11's fundamental soundness, but confirmed the authors' belief that the rendering system in X was woefully inadequate. One of us participated in the original X11 design meetings where the intent was to augment the rendering design at a later date; but the ``GUI Wars'' of the late 1980's doomed effort in this area. Good printing support has been particularly difficult to implement in X applications, as fonts have were opaque X server side objects not directly accessible by applications. 最急需解决的问题是X那陈旧的2维点阵文字和图形系统。1997年到2000年进行的Gnome和KDE GUI环境开发显示了X11的基础是稳固的，但是也证实了发起人的信念：X的渲染系统是很不充分的。我们中的一位参加了最初的X11设计会议，其目的是在未来增加渲染设计。但是80年代末的"GUI战争"使得这注定是件困难的事。良好的打印支持已经在X应用程序中实现，但由于字体是位于X服务器端的、应用程序不可见，不可直接访问的一个对象，所以这个实现做得非常艰难。 Most applications now composite images in sophisticated ways, whether it be in Flash media players, or subtly as part of anti-aliased characters. Bit-Blit is not sufficient for these applications, and these modern applications were (if only by their use of modern toolkits) all resorting to pixel based image manipulation. The screen pixels are retrieved from the window system, composited in clients, and then restored to the screen, rather than directly composited in hardware, resulting in poor performance. Inspired by the model first implemented in the Plan 9 window system, a graphics model based on Porter/Duff [PD84] image compositing was chosen. This work resulted in the X Render extension [Pac01a]. 现在，大多数应用程序通过非常复杂的途径来混合图像，无论Flash媒体播放器还是精巧的抗锯齿字符。对于这些应用程序来说，点阵是不足够的。这些现代的应用程序（如果它们采用现代toolkit）都采用基于像素的图像处理技术来进行混合。客户应用程序从窗口系统取得屏幕图像，自己进行混合，然后恢复到在屏幕上，而不是直接用硬件进行混合，这导致了非常低下的性能。受最早在Plan 9窗口系统中实现的模型的启发，一个基于Porter/Duff[PD84]图像混合的图形模型被选中来解决这个问题。这项工作产生了X Render扩展[Pac01a]。 X11's core graphics exposed fonts as a server side abstraction. This font model was, at best, marginally adequate by 1987 standards. Even WYSIWYG systems of that era found them insufficient. Much additional information embedded in fonts (e.g. kerning tables) were not available from X whatsoever. Current competitive systems implement anti-aliased outline fonts. Discovering the Unicode coverage of a font, required by current toolkits for internationalization, was causing major performance problems. Deploying new server side font technology is slow, as X is a distributed system, and many X servers are seldom (or never) updated. 在X11中，字体是服务器端的一个抽象概念。这个字体模型最多能勉强满足1987年的标准。恰好那时期的所见即所得系统发现了它们的不足。许多嵌入在字体中的附加信息（例如字距调整表）对X无论如何都是不可用的。当前竞争系统已经实现了抗锯齿的轮廓字体。我们发现当前toolkit为实现国际化所必需的Unicode字体是导致性能低下的一个主要原因。部署新的服务器端字体技术是缓慢的，因为X是一个分布式系统，很多X服务器很少或者从不升级。 Therefore, a more fundamental change in X's architecture was undertaken: to no longer use server side fonts at all, but to allow applications direct access to font files and have the window system cache and composite glyphs onto the screen. 因此，一个对X架构更根本的改变开始了：完全不再使用服务器端字体，让应用程序直接访问字体文件，窗口系统缓存和混合图像到屏幕。 The first implementation of the new font system [Pac01b] taught a vital lesson. Xft1 provided anti-aliased text and proper font naming/substitution support, but reverted to the core X11 bitmap fonts if the Render extension was not present. Xft1 included the first implementation what is called ``subpixel decimation,'' which provides higher quality subpixel based rendering than Microsoft's ClearType [Pla00] technology in a completely general algorithm. 新字体系统的第一次实现[Pac01b]给我们上了生动的一课。Xft1提供了抗锯齿文字和合适的字体命名/替换支持，但当没有Render扩展时它又重新采用X11的点阵字体。在Xft1中第一次实现了一项名为"子像素平滑"的技术，它为基于子像素的渲染提供了比微软的ClearType技术更好的质量，并且它使用的完全是常规的算法。 Despite these advances, Xft1 received at best a lukewarm reception. If an application developer wanted anti-aliased text universally, Xft1 did not help them, since it relied on the Render extension which had not yet been widely deployed; instead, the developer would be faced with two implementations, and higher maintenance costs. This (in retrospect obvious) rational behavior of application developers shows the high importance of backwards compatibility; X extensions intended for application developers' use must be designed in a downward compatible form whenever possible, and should enable a complete conversion to a new facility, so that multiple code paths in applications do not need testing and maintenance. These principles have guided later development. 虽然有这些先进的地方，Xft1只是被冷淡的接受。如果一个应用程序开发者想要在任何情况下都能显示抗锯齿字体，那么Xft1帮不了他们。因为 Xft1依赖于Render扩展，但它还没有被广泛部署。开发者会面对两个实现和更高的维护成本。从前的应用程序开发者的理智行为显示向后兼容是非常重要的。用来给应用程序开发者使用的X扩展必需设计成无论何时都得向下兼容，并且应该允许完全转换到一个新的设施上，这样才能使得应用程序中的多代码通路 (multiple code paths)不需要测试和维护。这些原则已经指导了后来的开发工作。 The font installation, naming, substitution, and internationalization problems were separated from Xft into a library named Fontconfig [Pac02], (since some printer only applications need this functionality independent of the window system.) Fontconfig provides internationalization features in advance of those in commercial systems such as Windows or OS X, and enables trivial font installation with good performance even when using thousands of fonts. Xft2 was also modified to operate against legacy X servers lacking the Render extension. 字体安装、命名、替换和国际化的问题从Xft中分开来，作为一个库，命名为Fontconfig[Pac02]（因为一些打印机应用程序需要这个功能独立于窗口系统）。Fontconfig提供了国际化功能，这超越了商业系统，例如Windows或OS X。即使使用了上千种字体，日常的字体安装工作还具有良好的性能。Xft2被修改为可以对传统的缺乏Render扩展的X服务器进行操作。 Xft2 and Fontconfig's solving of several major problems and lack of deployment barriers enabled rapid acceptance and deployment in the open source community, seeing almost universal use and uptake in less than one calendar year. They have been widely deployed on Linux systems since the end of 2002. They also ``future proof'' open source systems against coming improvements in font systems (e.g. OpenType), as the window system is no longer a gating item for font technology. Xft2和Fontconfig解决了数个主要的问题并且开发容易，这让开源社区能够很快的接受和进行开发工作，一年内它们已经被全部采纳和使用了。从2002年底，它们已经广泛的部署在Linux系统上。同时，它们能够让开源系统在将来使用更好的字体系统（例如OpenType），因为窗口系统已经不是字体技术的一个门槛了。 Sun Microsystems implemented a server side font extension over the last several years; for the reasons outlined in this section, it has not been adopted by open source developers. Sun微系统公司在过去数年中实现了一个服务器端的字体扩展。但它没有被开源开发者接纳，原因在本节的大纲中已经提到了。 While Xft2 and Fontconfig finally freed application developers from the tyranny of X11's core font system, improved performance [PG03], and at a stroke simplified their printing problems, it has still left a substantial burden on applications. The X11 core graphics, even augmented by the Render extension, lack convenient facilities for many applications for even simple primitives like splines, tasteful wide lines, stroking paths, etc, much less provide simple ways for applications to print the results on paper. 虽然Xft2和Fontconfig最终让应用程序开发人员从X11的核心字体系统中解脱出来，改进了性能，并且很巧妙的简化了它们的打印问题，但是应用程序还有一个巨大的负担 -- X11的核心图形。虽然Render扩展已经对其进行了延伸，但仍缺乏某些应用程序所需的如绘制spline，tasteful wide lines，stroking paths等的功能，更不用说为应用程序提供打印结果到纸张上面的简单途径了。 Cairo 三、Cairo The Cairo library [WP03], developed by one of the authors in conjunction with by Carl Worth of ISI, is designed to solve this problem. Cairo provides a state full user-level API with support for the PDF 1.4 imaging model. Cairo provides operations including stroking and filling Bézier cubic splines, transforming and compositing translucent images, and anti-aliased text rendering. The PostScript drawing model has been adapted for use within applications. Extensions needed to support much of the PDF 1.4 imaging operations have been included. This integration of the familiar PostScript operational model within the native application language environments provides a simple and powerful new tool for graphics application development. 由Keith Packard和ISI的Carl Worth共同开发的Cairo函数库正是为解决这个问题而设计的。Cairo提供了一个正式的用户层API，它支持PDF 1.4图像模型。Cairo提供的操作包括stroking和填充贝赛尔曲线，变换和混合半透明图像，以及抗锯齿字体渲染。PostScript绘图模型被修改为适合应用程序使用。其中还包括了为支持大多数PDF 1.4图像操作而做的扩展。它把熟知的PostScript操作模型集成到固有的应用程序语言环境中，为图形应用程序开发提供了一个简单和强大的新工具。 Cairo's rendering algorithms use work done in the 1980's by Guibas, Ramshaw, and Stolfi [GRS83] along with work by John Hobby [Hob85], which has never been exploited in Postscript or in Windows. The implementation is fast, precise, and numerically stable, supports hardware acceleration, and is in advance of commercial systems. Cairo的渲染算法采用了80年代Guibas、Ramshaw和Stolfi[GRS83]所做的工作成果以及John Hobby[Hob85]所做的工作成果。它们都没有在PostScript或者Windows中被采用。这个实现是快速的、精确的，数值是可靠的，还能支持硬件加速，它比商业系统更先进。 Of particular note is the current development of Glitz [NR04], an OpenGL backend for Cairo, being developed by a pair of master's students in Sweden. Not only is it showing that a high speed implementation of Cairo is possible, it implements an interface very similar to the X Render extension's interface. More about this in the OpenGL section below. 我们来特别地关注一下Glitz[NR04]当前的开发工作。Glitz是Cairo的一个OpenGL后端，它由瑞典的两个硕士研究生开发。它不但显示了高速实现Cairo是可能的，还实现了一个非常类似于X Render扩展接口的界面。下面的OpenGL一节将会提供更多的信息。 Cairo is in the late stages of development and is being widely adopted in the open source community. It includes the ability to render to Postscript and a PDF back end is planned, which should greatly improve applications' printing support. Work to incorporate Cairo in the Gnome and KDE desktop environments is well underway, as are ports to Windows and Apple's MacIntosh, and it is being used by the Mono project. As with Xft2, Cairo works with all X servers, even those without the Render extension. Cairo处于开发的后期阶段，它正在被开源社区广泛的接纳。它已经计划提供渲染到PostScript和PDF后端的能力，这将极大地提高应用程序的打印支持。集成Cairo到Gnome和KDE桌面环境的工作正在顺利进行中，它同时会被移植到Windows和Apple的MacIntosh，它已经在Mono项目中使用。如同Xft2那样，Cairo可以跟所有的X服务器配合工作，即使它没有Render扩展。 Accessibility and Eye-Candy 四、辅助功能和炫目的玩意 Several years ago, one of us implemented a prototype X system that used image compositing as the fundamental primitive for constructing the screen representation of the window hierarchy contents. Child window contents were composited to their parent windows which were incrementally composed to their parents until the final screen image was formed, enabling translucent windows. The problem with this simplistic model was twofold - first, a naïve implementation consumed enormous resources as each window required two complete off screen buffers (one for the window contents themselves, and one for the window contents composited with the children) and took huge amounts of time to build the final screen image as it recursively composited windows together. Secondly, the policy governing the compositing was hardwired into the X server. An architecture for exposing the same semantics with less overhead seemed almost possible, and pieces of it were implemented (miext/layer). However, no complete system was fielded, and every copy of the code tracked down and destroyed to prevent its escape into the wild. 很多年以前，我们中的一个实现了一个原型X系统，它采用图像混合作为基本原语来在屏幕上表现窗口分层内容。子窗口内容混合到它们的父窗口，而父窗口也同样的混合到它们的父窗口中，直到最终的屏幕图像建立起来。这种方法可以实现半透明窗口。这个简单模型的问题有两方面：第一，因为每一个窗口都需要两个完全的离屏缓存（一个是窗口自身的内容，一个是和子窗口混合后的窗口内容），所以这会消耗掉极大的资源。并且由于它是递归地把窗口混合在一起，所以生成一个最终的屏幕图像将会很费时间。第二，混合是由X服务器来管理的。一个能实现相同功能并且开销更小的体系结构是可行的，它的一部分已经实现了 (miext/layer)。然而，一个完整的系统还没有被实现，每一份该代码的拷贝都被追踪并且销毁，以防它失控。 Both Mac OS X and DirectFB [Hun04] perform window-level compositing by creating off-screen buffers for each top-level window (in OS X, the window system is not nested, so there are only top-level windows). The screen image is then formed by taking the resulting images and blending them together on the screen. Without handling the nested window case, both of these systems provide the desired functionality with a simple implementation. This simple approach is inadequate for X as some desktop environments nest the whole system inside a single top-level window to allow panning, and X's long history has shown the value of separating mechanism from policy (Gnome and KDE were developed over 10 years after X11's design). The fix is pretty easy--allow applications to select which pieces of the window hierarchy are to be stored off-screen and which are to be drawn to their parent storage. Mac OS X 和 DirectFB [Hun04] 执行窗口级的混合的过程是：为每一个顶级窗口（在OS X中，窗口系统是非嵌套的，所以它只有顶级窗口）创建离屏缓存，然后混合它们来生成屏幕图像。除了是否需要处理嵌套窗口之外，这两个系统都以一个简单的实现提供了预期的功能。这个简单的方法对X来说是不足的，因为一些桌面环境在一个顶级窗口中嵌套了整个系统，以此实现漫游，而且X漫长的历史也显示了分开策略和机制的价值（Gnome和KDE是在X11设计10年后才开发的）。调整是相当简单的--允许应用程序选择窗口等级的哪一部分保存到离屏缓存，哪一部分直接绘制到父窗口中。 With window hierarchy contents stored in off-screen buffers, an external application can now control how the screen contents are constructed from the constituent sub-windows and whatever other graphical elements are desired. This eliminated the complexities surrounding precisely what semantics would be offered in window-level compositing within the X server and the design of the underlying X extensions. They were replaced by some concerns over the performance implications of using an external agent (the ``Compositing Manager'') to execute the requests needed to present the screen image. Note that every visible pixel is under the control of the compositing manager, so screen updates are limited to how fast that application can get the bits painted to the screen. 由于窗口阶层内容保存在离屏缓存，现在一个外部应用程序可以控制如何从子窗口构造屏幕内容以及是否需要（加入）其它图形元素。这消除了围绕在X服务器内部实现窗口级混合所要提供的精确语义和基础X扩展设计的复杂性。使用一个外部代理（混合管理器）来执行显示屏幕图像所需的请求能够提高性能。注意每一个可视的像素都在混合管理器的控制之下，所以应用程序把点画到屏幕上的速度限制了屏幕更新速度。 The architecture is split across three new extensions: * Composite, which controls which sub-hierarchies within the window tree are rendered to separate buffers. * Damage, which tracks modified areas with windows, informing the Composting Manager which areas of the off-screen hierarchy components have changed. * Xfixes, which includes new Region objects permitting all of the above computation to be performed indirectly within the X server, avoiding round trips. 这个架构分为三个新的扩展： * Composite：控制窗口树中的哪一个子分层应绘制到分散的缓存中。 * Damage: 跟踪窗口中有变化的区域，通知混合管理器离屏阶级元件的哪个区域变化了。 * Xfixes: 包含了一个新的区域对象，允许上面所有的运算与X服务器分开执行，避免一连串的失误。 Multiple applications can take advantage of the off screen window contents, allowing thumbnail or screen magnifier applications to be included in the desktop environment. 许多应用程序可以从离屏窗口中获得好处：如可以在桌面环境中包含预览功能或者屏幕放大镜应用程序。 To allow applications other than the compositing manager to present alpha-blended content to the screen, a new X Visual was added to the server. At 32 bits deep, it provides 8 bits of red, green and blue along with 8 bits of alpha value. Applications can create windows using this visual and the compositing manager can composite them onto the screen. 为了允许除混合管理器外的应用程序在屏幕显示alpha混合内容，一个新的X Visual被添加到服务器。在32位颜色深度时，它提供了8位的红、绿、蓝色以及8位的alpha值。应用程序可以用这个visual建立窗口，混合管理器可以把它们混合到屏幕上。 Nothing in this fundamental design indicates that it is used for constructing translucent windows; redirection of window contents and notification of window content change seems pretty far removed from one of the final goals. But note the compositing manger can use whatever X requests it likes to paint the combined image, including requests from the Render extension, which does know how to blend translucent images together. The final image is constructed programmatically so the possible presentation on the screen is limited only by the fertile imagination of the numerous eye-candy developers, and not restricted to any policy imposed by the base window system. And vital to rapid deployment, most applications can be completely oblivious to this background legerdemain. 这个原则设计没有什么可以表明这是为了构造半透明窗口而做的。重定向窗口内容和通告窗口内容变化看起来离最终目标非常遥远。但注意，混合管理器可以使用任何它喜欢的X请求来绘画组合图像，包括Render扩展的请求，它知道怎样把半透明图像混合在一起。最终的图像的构造是可编程的，所以屏幕上能呈现出的效果由众多的eye-candy开发者的想象力决定，它没有被基本窗口系统的策略所限制。另外，对快速部署来说非常重要的是，大多数应用程序对这些幕后戏法是完全不可知的。 In this design, such sophisticated effects need only be applied at frame update rates on only modified sections of the screen rather than at the rate applications perform graphics; this constant behavior is highly desirable in systems. 这个设计中，如此复杂的效果只需以帧更新速度作用于屏幕更改区域，而不是应用程序执行图形操作的速度，这种恒定的行为在系统中是非常可取的。 There is very strong ``pull'' from both commercial and non-commercial users of X for this work and the current early version will likely be shipped as part of the next X.org Foundation X Window System release, sometime this summer. Since there has not been sufficient exposure through widespread use, further changes will certainly be required further experience with the facilities are gained in a much larger audience; as these can be made without affecting existing applications, immediate deployment is both possible and extremely desirable. 这项工作对无论是商业还是非商业的X用户来说都是具有很大吸引力的，它的早期版本将会随X.org基金会的下一版X窗口系统发布时一起提供，或许是这个夏季。因为它没有经过大范围的使用来暴露其不足，所以将来是一定需要修改的。未来这个特效所带来的体验将会使其获得很多的用户。因为它不影响现存的应用程序，所以即时部署是可行并且非常值得去做的。 The mechanisms described above realize a fundamentally more interesting architecture than either Windows or Mac OSX, where the compositing policy is hardwired into the window system. We expect a fertile explosion of experimentation, experience (both good and bad), and a winnowing of ideas as these facilities gain wider exposure. 上面描述的机制实现了一个根本上比Windows或者Mac OSX更有趣的的体系，后两者的混合策略是在窗口系统中实现的。我们盼望有许多的实验、体验（好的或不好的），以及一大堆供筛选的建议能够在更大范围暴露其不足。 Input Transformation 五、输入转换 In the ``naïve'', eye candy use of the new compositing functions no transformation of input events are required, as input to windows remains at the same geometric position on the screen, even though the windows are first rendered off screen. More sophisticated use, for example, screen readers or immersive environments such as Croquet [SRRK02], or Sun's Looking Glass [KJ04] requires transformation of input events from where they first occur on the visible screen to the actual position in the windows (being rendered from off screen), since the window's contents may have been arbitrarily transformed or even texture mapped onto shapes on the screen. [待翻译] As part of Sun Microsystem's award winning work on accessibility in open source for screen readers, Sun has developed the XEvIE extension [Kre], which allows external clients to transform input events. This looks like a good starting point for the somewhat more general problem that 3D systems pose, and with some modification can serve both the accessibility needs and those of more sophisticated applications. 作为Sun Microsystem公司在开源屏幕阅读器这一辅助功能所做的杰出工作的一部分，Sun开发了XEvIE扩展，它允许外部客户程序改变输入事件。看起来这对比摆姿态的3D系统更普通的问题是一个很好的开始，只要做一些修改，它就能满足辅助功能和那些更复杂的应用程序的需求。 Synchronization 六、同步 Synchronization is probably the largest remaining challenge posed by compositing. While composite has eliminated much flashing of the screen since window exposure is eliminated, this does not solve the challenge of the compositing manager happening to copy an application's window to the frame buffer in the middle of an application painting a sequence of updates. No ``tearing'' of single graphics operations take place since the X server is single threaded, and all graphics operations are run to completion. 同步大概是混合之外剩下的最大挑战了。虽然由于混合消除了窗口暴露，因而消除了屏幕的大部分闪烁。但是这并没有解决一个应用程序进行一系列绘图更新时，碰巧混合管理器复制它的窗口到帧缓存这样的情况。进行单一的图形操作是没问题的，因为X服务器是单线程的，所有的图形操作都是序列化的。 The X Synchronization extension (XSync) [GCGW92], widely available but to date seldom used, provides a general set of mechanisms for applications to synchronize with each other, with real time, and potentially with other system provided counters. XSync's original design intent intended system provided counters for vertical retrace interrupts, audio sample clocks, and similar system facilities, enabling very tight synchronization of graphics operations with these time bases. Work has begun on Linux to provide these counters at long last, when available, to flesh out the design originally put in place and tested in the early 1990's. 广泛存在但至今为止很少用到的X同步扩展(XSync)[GCGW92]，提供了一个让应用程序之间相互同步的机制的常规集合。并且它是实时的，而其它系统却是相反的。 A possible design for solving the application synchronization problem at low overhead may be to mark sections of requests with increments of XSync counters: if the count is odd (or even) the window would be unstable/stable. The compositing manager might then copy the window only if the window is in a stable state. Some details and possibly extensions to XSync will need to be worked out, if this approach is pursued. [待翻译] Next Steps 七、下一步 We believe we are slightly more than half way through the process of rearchitecting and reimplementing the X Window System. The existing prototype needs to become a production system requiring significant infrastructure work as described in this section. [待翻译] OpenGL based X 7.1 基于OpenGL的X Current X-based systems which support OpenGL do so by encapsulating the OpenGL environment within X windows. As such, an OpenGL application cannot manipulate X objects with OpenGL drawing commands. 当前基于X的系统是通过把OpenGL环境封装进X窗口的形式来支持OpenGL的。这样一来，一个OpenGL应用程序就不能通过OpenGL绘图命令来操作X对象了。 Using OpenGL as the basis for the X server itself will place X objects such as pixmaps and off-screen window contents inside OpenGL objects allowing applications to use the full OpenGL command set to manipulate them. 使用OpenGL作为X服务器的基础将可以把如图像和离屏窗口内容的X对象放到OpenGL对象中，允许应用程序使用全部OpenGL命令集来操作它们。 A ``proof of concept'' of implementation of the X Render extension is being done as part of the Glitz back-end for Cairo, which is showing very good performance for render based applications. Whether the ``core'' X graphics will require any OpenGL extensions is still somewhat an open question. [待翻译] In concert with the new compositing extensions, conventional X applications can then be integrated into 3D environments such as Croquet, or Sun's Looking Glass. X application contents can be used as textures and mapped onto any surface desired in those environments. [待翻译] This work is underway, but not demonstrable at this date. [待翻译] Kernel support for graphics cards 7.2 内核支持图形卡 In current open source systems, graphics cards are supported in a manner totally unlike that of any other operating system, and unlike previous device drivers for the X Window System on commercial UNIX systems. There is no single central kernel driver responsible for managing access to the hardware. Instead, a large set of cooperating user and kernel mode systems are involved in mutual support of the hardware, including the X server (for 2D graphic), the direct-rendering infrastructure (DRI) (for accelerated 3D graphics), the kernel frame buffer driver (for text console emulation), the General ATI TV and Overlay Software (GATOS) (for video input and output) and alternate 2D graphics systems like DirectFB. 当前开源系统以一种独特的方式来支持图形卡。它完全不同于其它操作系统，也不同于以前的商业UNIX系统中的X窗口系统的设备驱动。它没有单一的内核驱动负责对硬件的访问管理。取而代之的是用户模式系统和内核模式系统之间相互协作，很混乱的共同支持硬件的一个大集合，其中包括X服务器（2D图形），直接渲染机构（DRI）（加速3D图形），内核帧缓存驱动（字符控制台仿真），普通的AIT TV和覆盖(Overlay)软件（GATOS）（视频输入和输出），以及其它候选的2D图形系统，如DirectFB。 Two of these systems, the kernel frame buffer driver and the X server both include code to configure the graphics card ``video mode''--the settings needed to send the correct video signals to monitors connected to the card. Three of these systems, DRI, the X server and GATOS, all include code for managing the memory space within the graphics card. All of these systems directly manipulate hardware registers without any coordination among them. 这些系统中的2个，内核帧缓存驱动和X服务器都包含了配置图形卡"视频模式"（该配置需要发送正确的视频信号到连接到卡上面的显示器）的代码。这些系统中的3个，DRI、X服务器和GATOS，都包含管理图形卡内部内存空间的代码。这些系统都在没有协调的情况下直接操纵硬件寄存器。 The X server has no kernel component for 2D graphics. Long-latency operations cannot use interrupts, instead the X server spins while polling status registers. DMA is difficult or impossible to configure in this environment. Perhaps the most egregious problem is that the X server reconfigures the PCI bus to correct BIOS mapping errors without informing the operating system kernel. Kernel access to devices while this remapping is going on may find the related devices mismapped. 对于2D图形操作，X服务器没有内核组件。具有长时间的传输延迟的操作不能使用中断，取而代之，X服务器循环询问状态寄存器。DMA是很困难或者不可能在这个环境中使用的。可能最惊人的问题是X服务器在没有通知操作系统内核的情况下重新配置PCI总线来修正BIOS映射错误。内核在重映射的时候访问设备将会发现相关设备映射错误。 To rationalize this situation, various groups and vendors are coordinating efforts to create a single kernel-level entity responsible for basic device management, but this effort has just begun. 为了合理的解决这种状况，不同的小组和厂商协作努力建立一个单一内核驱动负责基本的设备管理，但这个努力才刚刚开始。 Housecleaning and Latency Elimination and Latency Hiding [待翻译] ... [待翻译] Mobility, Collaboration, and Other Topics 7.4 移动、协作和其它话题 ... [待翻译] Color Management 7.5 颜色管理 ... [待翻译] Security and Authentication 7.6 安全和认证 ... [待翻译] Compression and Image Transport 7.7 压缩和图像传输 ... [待翻译] Bibliography 参考文献 ... [待翻译]