wayland与linux_百度贴吧:linux吧，一个关于Wayland的比较精彩的回答

网友(zasdfgbnm)的问题标题是：Wayland能给Linux桌面带来多大提升？

问题内容：貌似wayland只是简化了手续，还是采用网络连接来进行这些工作的呀？网络连接本身就慢，简化一下手续能快很多么？比起Win以及Mac直接调用系统调用，应该还是延迟大吧？

楼中，网友一直争论不休，终于出来一个牛人(mephistohk)，从此，留言止于此。

内容如下：

X 架构中部分特征已经不适应现代需求导致了 wayland 的诞生

X

的好处如网络透明性之类的就不多说了，有机会感受过的自然明白。这里专门来说说 X

的缺点。不过话说头里，任何缺点都是相对的，需要联系其发生的场合来介定。一个极端的例子就是：对于大多数时间来说，人类顽强的生命力自然是大大的优点，

但对于身患绝症痛得死去活来，或者正在承受酷刑(如凌迟)的人来说，生命力顽强反倒是最大的缺点了，此时早日解脱才是最好的结局。

X 最主要的两大缺点：

X

协议本质上是同步的，这意味着 X

无法及时处理需要优先响应的消息。这在早期并不是什么大问题，因为那时基本上输出的内容都是矢量化的图形数据，处理速度很快。现在则不同，花里胡哨的界面

大部分需要通过位图来渲染，这就使得 X 必须将很多时间花在传输点阵数据上，如果此时用户频繁移动鼠标并执行点击等操作，由于 X

协议的同步特性，服务器必须等当前数据传完才向 XClient 发送消息。从累积响应上看，用户自然就觉得系统响应有缓慢的感觉了。

XServer

是一个集中信息处理系统，它负责从 XClient 进程接收绘图指令，并将本地的输入设备产生的数据转换为消息发送到 XClient

进程。这个过程看似简单，但实际上流程比较复杂，极端情况下，当 XServer

获得输入设备产生的数据后，它先要发送给窗口管理器(窗口管理器很可能还在另一台主机上，需要通过网络传输)，再接收窗口管理器发出的请求，再将输入数据

发送到真正的 XClient(又有可能通过网络)，XClient 处理完消息后向 XServer 发送绘图请求(又有可能是网络)，再由

XServer 执行绘图渲染工作，这其中如果使用到的字体不在本地，还要通过访问字体服务器(又有可能是网络)获取字体数据后再行渲染。而花哨到极点的

compize

之类的聚合窗口管理器因为需要在多个XClient产生的窗口上进行复合渲染，造成XClient递交的绘图指令被多次重复运行，更是让XServer在

效率上雪上加霜。

至于其它关于XServer过度依赖扩展，缺少桌面概念，缺乏简明的拖拽支持，以及用户态的运行级别等等一系列的问题反而是小儿科了。

综

上所述，是因为 X

过长的生命周期，使得它的部分设计理念随着时间推移已经过时，无法适应现代用户对计算机图形界面的特殊需求才导致的缺点。其实在很多专业领域里，以上两点

并不算缺点，相反还是优点(例如在战场指挥系统，计算机集群计算等等场合)，因此 X 在这里依旧是无法取代的。

以上这两大缺点是 X 体系架构上的缺点，本质上是无法彻底改变的。因此，为了适应人们对现代图形界面的需求，Wayland 自然而然地就诞生了。

Wayland

到底有什么好处这里就不详细说了，因为 Wayland 的文档里已经说得非常明白了。总之，Wayland 是站在 X

肩膀上发展起来的，它在意识到 X 架构上的缺陷无法通过在 X 基础上进行扩展来完成时，选择了重新设计来试图彻底地解决 X 这两大缺陷。

根据上面发帖网友的问到的 Wayland 是否使用 socket 的疑问。这里以文档 《Documentation0.1 Wayland》，以及 Wayland 相关源码为依据回答一下：

答

案：是的，根据文档中 3.3.Wire Format 节显示，当前 Wayland 协议使用 Unix

域套接字，并使用消息通信。同时文档中也提到，这在将来可能是会改变的。因为使用了sendmsg()，所以它目前离不开 tcp/ip

协议支持。同时因为 display->fd

是由客户程序创建的，因此在未来也有可能会支持到通过其它更高效的进程间通信手段，甚至直接通过线程间通信来完成。

具体在 Wayland 源码中显示为：

/* 位于 wayland/src/wayland-client.c 中 */

display->fd = socket(PF_LOCAL, SOCK_STREAM | SOCK_CLOEXEC, 0);

/* 位于 wayland/src/wayland-server.c 中 */

s->fd = socket(PF_LOCAL, SOCK_STREAM | SOCK_CLOEXEC, 0);

/* 位于 wayland/src/connection.c 中 */

len = sendmsg(connection->fd, &msg, MSG_NOSIGNAL);

len = recvmsg(connection->fd, &msg, MSG_CMSG_CLOEXEC);

当

然基于 tcp/ip, wayland

更可以通过网络实现透明性，想象一下网速普及到G级时，网络不在时瓶颈时，传输延时还感觉的出来吗？这个时刻至少在LAN环境中是很快会到来的。即使是百

兆网，当前除了直接传输未压缩的多媒体数据外，一般应用来说已经不成问题了(硬件环境的发展速度是惊人的)。

虽然 Wayland

仍旧是基于进程间通信的模型，但与 X

不同的是它将现代图形界面应用中对用户体验最为重要的，同时也是开销最大的图象聚合渲染部分独立成一个专门的聚合渲染进程并取代了

XServer，同时采用了异步的消息通信机制，这就在根本上避免了 X 中带来效率问题的两大缺点，从而大大提高了用户体验，同时又不失 X

的灵活性，而且还能兼容 X。从这个意义上讲，Wayland 是 X

这个优秀架构基于现代计算机应用环境的重新实现，它充分应用了现代计算机环境提供的优越条件，并继承了 X 的设计思想，的确很有独到之处。

如果需要详细了解 Wayland 的细节，推荐阅读文档《Documentation0.1 Wayland》，里面说的非常详细。同时也可以参阅 Wayland 的源码。

再

多说几句：以前我曾经阅读过 XFree86 的大部分源码，在阅读完 Wayland 的源码并与 XFree86 进行了一定程度的比较后，我本人对

Wayland 在设计上是很看好的。不过因为 Wayland 本身并不完全是为了与 Windows 或 Mac OS

竞争而设计，因此大家最好不要试图把 Wayland 当成 Windows 或 Mac OS 的克星。Wayland

关注的依旧是专业化应用，而不是试图谄媚市场。所以，Wayland 的未来，任重而道远！！！

感觉这位大哥(mephistohk)写的比较好，特此转来。