桌系统的混成器简史.PDF

桌⾯系统的混成器 简史
⽬录 早期的栈式窗⼝管理器 NeXTSTEP
与
Ma
OS
X
中混成器的发展 插曲 ：昙花⼀现的
Proje t
Looking
Glass
3D Windows
中的混成器 这就结束了？
Linux
桌⾯呢？ Loading
[MathJax]/jax/output/HTML-CSS/jax.js （原本是想写篇关于
Wayland
的⽂章，后来越写越 ⻓感觉能形成⼀个系列，
于是就先把这篇背景介绍性质 的部分发出来了。） Linux
系统上要迎来
Wayland
了，或许⼤家能从各 种渠道打听到
Wayland
是⼀个混成器，替代
X
作为显⽰ 服务器。
那么
混混成成器器
是个什么东⻄，桌⾯系统为什么需 要它呢？
要理解为什么桌⾯系统需要
混混成成器器
（或者它的 Compositing
Window
Manager 另⼀个叫法，
混成窗⼝管理器
），在这篇⽂章中我想回 顾⼀下历史，
了解⼀下混成器出现的前因后果。 ⾸先介绍⼀下混成器出现前主要的⼀类窗⼝管理 Sta king
Window
Manager 器，也就是
栈式窗⼝管理器
的实现⽅式。 本本⽂⽂中中所所有有桌桌⾯⾯截截图图来来⾃⾃维维基基百百科科，，不不具具有有著著作作权权保保护护。。 早期的栈式窗⼝管理器 栈式窗⼝管理器的例⼦，Windows
3.11
的桌⾯ 我们知道最初图形界⾯的应⽤程序是全屏的，独占 整个显⽰器 （现在很多游戏机和⼿持设备的实现仍旧如 此）。
所有程序都全屏并且任何时刻只能看到⼀个程序 的输出，这个限制显然不能满⾜⼈们使⽤计算机的需 求，
于是就有了
窗⼝
的概念，有了
桌⾯隐喻
。 Desktop
Metaphor 在
桌⾯隐喻
中每个窗⼝只占⽤显⽰⾯积的⼀⼩部 分，
有其显⽰的位置和⼤⼩，可以互相遮盖。于是栈式 窗⼝管理器就是在图形界⾯中实现桌⾯隐喻的核⼼功 能，
其实现⽅式⼤体就是 ：给每个窗⼝⼀个相对的“⾼ 度”或者说“远近”，⽐较⾼的窗⼝显得距离⽤户⽐较近， 会覆盖其下⽐较低的窗⼝。绘图的时候窗⼝管理器会从 把窗⼝按⾼低排序，按照从低到⾼的顺序使⽤
画家算法 绘制整个屏幕。 这⾥还要补充⼀点说明，在当时图形界⾯的概念刚 刚普及的时候，绘图操作是⾮常“昂贵”的。
可以想象⼀ 下
800x600
像素的显⽰器输出下，每帧
真彩⾊
位图就要 占掉
800
\times
600
\times
3
\approx
1.4
\text{MiB}
的 内存⼤⼩，30Hz
的刷新率 （也就是30FPS）下每秒从 CPU
传往绘图设备的数据单单位图就需要
1.4
\times
30 =
41
\text{MiB}
的带宽。对⽐⼀下当时的
VESA
接⼝
总 的数据传输能⼒也就是
25
\text{MHz}
\times
32 \text{bits}
=
100
\text{MiB/s}
左右，
⽽
Windows
3.1
的 最低内存需求是
1MB，对当时的硬件⽽⾔⽆论是显⽰设 备、内存或是CPU，
这⽆疑都是⼀个庞⼤的负担。 于是在当时的硬件条件下采⽤栈式窗⼝管理器有⼀ 个巨⼤
优优势势
：如果正确地采⽤画家算法，
并且合理地控 制重绘时
只只绘绘 没没有有被被别别的的窗窗⼝⼝覆覆盖盖的的部部分分
，那么⽆ 论有多少窗⼝互相
遮盖，都可以保证每次绘制屏幕的最 ⼤⾯积不会超过整个显⽰器的⾯积。
同样因为实现⽅式 栈式窗⼝管理器也有⼀些难以回避的
限限
： 1.
窗⼝必须是矩形的，不能⽀持不规则形状的窗⼝。 2.
不⽀持透明或者半透明的颜⾊。 3.
为了优化效率，在缩放窗⼝和移动窗⼝的过程中， 窗⼝的内容不会得到重绘请求，
必须等到缩放或 者移动命令结束之后窗⼝才会重绘。 以上这些限制在早期的
X11
窗⼝管理器⽐如
twm
以 及
XP
之前经典主题的
Windows
或者经典的
Ma
OS
上 都能看到。
在这些早期的窗⼝环境中，如果你拖动或者 缩放⼀个窗⼝，那么将显⽰变化后的窗⼝边界，
这些⽤ 来预览的边界⽤快速的位图反转⽅