企业官网建设流程全解析

目录

1、The Wayland Protocol

2、x11、wayland工作流程

（1）x11

（2）wayland

The Wayland Protocol —新手入门学习（二）

1、The Wayland Protocol

Wayland是什么呢？它是X Window？还是要取代X Window？Linux桌面/移动会因此有什么变化？在本篇中，我将回顾历史，通过简易的文字，来先回顾一下X Window，从而继续解答Wayland——古老的X Window和现代的桌面技术。

X Window在1984年由MIT研发，它的设计哲学之一是：提供机制，而非策略。举个最简单的例子吧：X Window提供了生成窗口（Window）的方法，但它没规定窗口要怎么呈现（map）或摆放，这个策略是由外部程序—窗口管理器（Window Manager）所决定的。另外一个XWindow的主要特点便是：Server/Client网络模型。不论是本地、远程的应用程序，都统一通过Server/client模型来运作，比如：让远程的应用程序跑在本地上。

X Window在推出之后快速演化，在1987年时候，其核心协议已经是第11版本了，简称：x11。这个版本已经将“提供机制，而非策略”这个哲学贯彻地非常彻底，以致于核心协议基本稳定，不需要特别大的改动。于是乎，20年后，X Window依然是x11。你可能会诧异，20年了，X Window的核心都没有特别大的变化，它能适应现代桌面的快速发展吗？这就要再次提到XWindow的设计优势了，X Window在核心层之外提供一个扩展层，开发者可以开发相应扩展，来实现自己的扩展协议，比方说：

标准的Window都是矩形的，我如何用它来画一个圆形的窗口？X Window协议并未提供，但是通过“shape”这个扩展，XWindow可以实现不规则的窗体。所以啊，这20年，X Window除了继续完善核心协议、驱动以外，很大程度上，都是扩展使它保持“与时俱进”，比如说：

1、要多头显示支持，这个是由“Xinerama”扩展实现的；

2、要有多媒体视频回放的支持，这个是由“X Video”扩展实现的；

3、OpenGL的3D支持，则是通过“GL”扩展来实现的；

4、Compiz那样的合成桌面特效是怎么弄的？它便是：“Composite”；

5、甚至Keyboard的支持，都是通过“xKeyboard Extension”（也就是“XKB”）的

X Window的核心，基本上就是在处理Server/Client、驱动之类的，而外部的那些支持，基本上全是通过“扩展”进行的。这没什么不好，X Window的结构设计精良，尽管是扩展，但它们没有任何效能上的问题。

通过扩展方便地实现了一些对新技术、新事物的支持，而且方便维护，这再好不过了。所以你看到了尽管20年过去了，基于X Window的GNOME、KDE，还能保持与同期Windows、Mac OS X 竞争，甚至某些方面更好。你就不得不佩服这些前辈在最初设计时定下的设计哲学是多么正确了。虽然扩展的众多没有给X Window造成什么问题，也跟XWindow的设计哲学相符，但是其Server/Client的网络构架，却一直倍受质疑。

这便是：X Window的效率问题，X Window的Server/Client结构严重影响效率，导致Linux桌面的效应速度一直不如WindowS、Mac OSX。让我们还是透过原理来解释。

2、x11、wayland工作流程

（1）x11

这张，便是当前X Window系统的架构图，稍微解释一下：

X Client：图形应用程序，如Firefox、Pidgin等；

X Server：你看不见的控制中心；

Compositor：合成桌面系统，如Compiz；

Kernel/KMS/evdevα：这便是LinuxKernel，后面会提到KMS技术了，其中还有一项evdev，是管

理输入设备的。

想像一下，当你点击了浏览器（xClient）的“刷新”按钮，将会发生以下事情：

1、你用鼠标点击了浏览器的“刷新”按钮，这时内核收到了鼠标发来的事件，并将其通过evdev输入。驱动发送至了XServer。这时内核实际上做了很多事情，包括将不同品牌的鼠标发出的不同信号转换成了标准的“evdev”输入信息。

2、这时XServer可以判断哪个Window该收到这个消息，并将某座标按下按钮的消息发往浏览器（xClient）但事实上xServer并不知道它得到的窗口信息是不是正确！

因为现在是“Composite”即合成桌面的时代，合成桌面的一个特点便是：Compositor（如Compiz）管理窗口的一切，×Server只能知道屏幕的某个坐标点收到了鼠标消息，却不知道这个点下面到底有没有窗口。

3、假设应用场景没这么复杂，浏览器（xCilent）顺利地收到了消息，这时浏览器（xCilent）要决定该如何做：按钮要有按下的效果。于是浏览器（xCilent）再发送请求给×Server，说：“麻烦画一下按钮按下的效果。"

4、当xServer收到消息后，它就准备开始做具体的绘图工作了：首先它告诉显卡驱动，要画怎么样一个效果，然后它也计算了被改变的那块区域，同时告诉Compiz那块区域需要重新合成一下。

5、Compiz收到消息后，它将从缓冲里取得显卡染出的图形并重新合成至整个屏幕一当然，Compiz的“合成”动作，也属于“渲染”，也是需要请求xServer，我要画这块，然后XServer回复：你可以画了。

xClient->XServer，再从XServer->Compositor，尽管Compiz已经掌管了全部最终桌面呈现的效果，但xServer在收到Compiz的“渲染”请求时，还会做一些“本职工作”，如：窗口的重叠判断、被覆盖窗口的剪载计算等等（不然它怎么知道鼠标按下的坐标下，是Firefox的窗口呢）一这些都是无意义的重复工作，而且Compiz不会理会这些，Compiz依然会在自己的全屏幕“画布”上，画着自己的动画效果……

从这个过程，基本可以得出结论：

X Client<-> X Server<->>Compositor，这三者请求染的过程，不是很高效；

（2）wayland

还记得前文中"点击浏览器（xCilent）的刷新按钮"这个应用场景吧？在Wayland里，所有的流程是这样的：

1、内核收到了鼠标发出的信息，经过处理后转发到了Wayland Compositor，就像之前发往X Server一样。

2、Compositor收到消息后，立马能知道哪个窗口该收到这个消息，因为它就是总控制中心，它掌握窗口的层级关系、动画效果，因此它知道该坐标产生的鼠标点击信息应该发送给谁，就这样，Compositor将鼠标的点击信息发送给了浏览器（xCilent）。

3、浏览器（xCilent）的收到了消息，这时如果是在X Window下的话，Firefox会向X Server请求绘制按钮被按下的效果。然而在Wayland里，浏览器（xCilent）可以自行进行绘制而不需要再请求Compositor的许可！这就是传说中的：直接渲染机制（Direct Render）！Wayland不管Client的绘制工作，整个过程变得十分简单而且高效！当浏览器（xCilent）自行完成了按钮状态的绘制后，它只需要通知Compositor，某块区域已经被更新了。

4、Compositor收到浏览器（xCilent）发来的信息的，再重新合成那块更新的那块区域，将最终桌面效果呈现给用户。这个过程主要是跟内核、显卡驱动打交道了。

从这个过程，基本可以得出结论：

1、Wayland的"直接渲染架构"彻底结束了传统X Window在渲染图形时需要不停的向Server请求、确认再绘制这个繁琐的过程，理论上响应速度有了"爆发式"增长；

2、Wayland从根本上消除了"Server+Compositor"的重复劳动，仅有且只需要有一个"Compositor"合成器而已。

Compostior，就是Wayland上的"X Server"，但是它更纯粹，它不像X Server一样，像个大家长，什么都要管。

Compositor只做该做的事情，把上面的过程简化成任务便是：

1、基于Wayland协议，处理evdev的信息；

2、通知Client（即应用程序）对相关事件做出反应（至于应用程序想怎么反应，Compositor不需要过问）；

3、收到Client的状态更新，重新合成图形或管理新的图形布局。

讲了这么多技术，大家肯定枯燥了，究竟现在有没有可以跑的"Wayland Compositor"呢？当然！现在，只要你从官方取得源码，然后根据教程进行编译，就能跑起一个简单实现的"Wayland Compositor"。

由于Wayland协议的灵活性，Wayland Compositor也可以拥有自己的后端：比如直接在DRM上跑Wayland（不需要X），或者在X Window上跑起一个Wayland Compositor（相当于在X Window上用Xephyr再跑一个X Window）。

当前我在UOS1050的图形环境下，就跑起了默认的这个简易的Wayland，几点说明：

• 支持透明、阴影和简单的窗口管理；
• 所有的图形绘制，都是通过Cairo-gl（Cairo的OpenGL后端）进行；

简单的说，它就是一个去除X Window中不必要的设计、充分利用现代Linux内核图形技术的一个显示机制，它的出现是自然而然的，它的使命不是为了消灭X Window，而是将Linux的图形技术发挥至更高的一个境界。传统的X Window（即经典X应用、Gtk 1.x/2.x等旧应用），也会在相当长一段时间内得到继续支持，通过Wayland Client的形式跑在Wayland Compositor上，直到最终升级、取代或被淘汰。