X 中的混成器与Composite 扩展.PDF

X
中的混成器与 Composite
扩展 ⽬录 原始的
X
的绘图模型 通过
Composite
扩展重定向 ⼝输出 输⼊事件的重定向，这可能做到么？ Composite
扩展的不⾜ 附录 ：扩展阅读 在上篇⽂章
「桌⾯系统的混成器简史」
中我介绍了 其它桌⾯系统中的混成器的发展史和⼯作原理，
话题回 到我们的正题
Linux
系统上，来说说⽬前
X
中混成器是 如何⼯作的。
这篇⽂章将⽐上⼀篇深⼊更多技术细节， 不想看太多细节的可以直接跳过看
结论
。 原始的
X
的绘图模型 ⾸先，没有混成器的时候
X
是这样画图的 ： X
的应⽤程序没有统⼀的绘图
API
。GTK+
在
3.0
之 后统⼀⽤
Cairo
绘图，
⽽
Cairo
则是基于
PDF
1.4
的绘 图模型构建的，
GTK
的
2.0
和之前的版本中也有很⼤⼀ 部分的绘图是⽤
Cairo
进⾏，
其余则通过
xlib
或者
xcb 调⽤
X
核⼼协议提供的绘图原语绘图。
QT
的情况也是类 似，基本上⽤
QPaint
⼦系统绘制成位图然后交给
X
的显 ⽰服务器。
显⽰服务器拿到这些绘制请求之后，再在屏 幕上的相应位置绘制整个屏幕。
当然还有很多⽼旧的不 ⽤
GTK
或者
QT
的程序，他们则直接调⽤
X
核⼼协议提 供的绘图原语。 值得注意⼀点是
X
上除了没有统⼀的绘图模型，也 没有统⼀的⽮量图格式。
X
核⼼协议的绘图原语提供的 是像素单位的绘图操作，没有类似
GDI+
或者
Quartz
提 Device
Independence 供的
设备⽆关
的 「点」的抽象。所以只⽤
X
的绘图原 语的话，我们可以把
(1,1)
这个像素点涂⿊，但是不能把 (0.5,
0.5)
这个点涂⿊，这⼀设计缺陷在
Unix
Haters
Handbook
中已经被吐槽过了。因为这个缺陷，所以直 接⽤
X
绘图原语绘制的图像不能像
⽮量图那样进⾏⽆损 缩放。同样的缺陷导致
X
绘图原语绘制的字符不能做到
subpixel-level anti-aliasing ⼦像素级
抗锯⻮
（这解释了默认配置下的
xterm
和
urxvt
中的字体渲染为什么难看
）。相⽐之下
GDI
有对 应的
WMF
⽮量图格式，
Quartz
有对应的
PDF
⽮量图格 式，
⽽
X
中没有这样的格式对应。因为没有统⼀的⽮量 图格式，所以⽆论是
Cairo
、QPaint
还是没有⽤这些绘 图库但是同样在意字体和曲线渲染效果的程序 （⽐如 Firefox
和
Chromium）都需要⾸先渲染到内部的
XPixMap
位图格式，做好⼦像素渲染和⽮量缩放，然后 再把渲染好的位图转交给
X
图形服务器。 通过
Composite
扩展重定 向 ⼝输出 2004年发布的
X11R6.8
版本的
Xorg
引⼊了
Composite
扩展
。这个扩展背后的动机以及前因后果在 ⼀篇⽂章
The
(Re)Architecture
of
the
X
Window
System
中有详细的表述。Composite
扩展允许某个
X 程序做这⼏件事情 ： 1.
通过
RedirectSubwindows
调⽤将⼀个 ⼝树 off-screen
storage 中的所有 ⼝渲染重定向到
内部存储
。重定向的 时候可以指定让
X
⾃动更新 ⼝的内容到屏幕上或 者由混成器⼿动更新。 2.
通过
NameWindowPixmap
取得某个 ⼝的内部 存储。 3.
通过
GetOverlayWindow
获得⼀个特殊的⽤于 绘图的 ⼝，
在这个 ⼝上绘制的图像将覆盖在 屏幕的最上⾯。 4.
通过
CreateRegionFromBorderClip
取得某个 ⼝的边界剪裁区域 （不⼀定是矩形）。 有了
Composite
扩展，⼀个
X
程序就可以调⽤这些 API
实现混成器。
这⾥有篇
教学解释如何使⽤
Composite
扩展
。开启了混成的
X
是这样绘图的 ： 整个
X
的混成器模型与
Mac
OS
X
的混成