在Wayland的架构图中，最显著的一些特点是： 它复用了所有Linux内核的图形、输入输出技术：KMS、evdev，因此已支持的驱动可以直接拿来用； Wayland没有传统的Server/Client的模式，取而代之的是：Compositor/Client，这不仅仅是换一个名称而已，后面会讲到具体区别；
还记得前文中“点击Firefox的刷新按钮”这个应用场景吧？在Wayland里，所有的流程是这样的：
内核收到了鼠标发出的信息，经过处理后转发到了Wayland Compositor，就像之前发往X Server一样。 Compositor收到消息后，立马能知道哪个窗口该收到这个消息，因为它就是总控制中心，它掌握窗口的层级关系、动画效果，因此它知道该坐标产生的鼠标点击信息应该发送给谁，就这样，Compositor将鼠标的点击信息发送给了Firefox。 Firefox收到了消息，这时如果是在X Window下的话，Firefox会向X Server请求绘制按钮被按下的效果。然而在Wayland里，Firefox可以自行进行绘制而不需要再请求Compositor的许
可！这就是传说 中的：直接渲染机制（Direct Render）！Wayland不管Client的绘制工作，整个过程变得十分简单而且高效！当Firefox自行完成了按钮状态的绘制后，它只需要通知 Compositor，某块区域已经被更新了。 Compositor收到Firefox发来的信息的，再重新合成那块更新的那块区域，将最终桌面效果呈现给用户。这个过程主要是跟内核、显卡驱动打交道了。 整个流程是不是很自然、很简单？
所以结论出来了：
Wayland的“直接渲染架构”彻底结束了传统X Window在渲染图形时需要不停的向Server请求、确认再绘制这个繁琐的过程，理论上响应速度有了“爆发式”增长； Wayland从根本上消除了“Server+Compositor”的重复劳动，仅有且只需要有一个“Compositor”合成器而已。 Compostior，就是Wayland上的“X Server”，但是它更纯粹，它不像X Server一样，像个大家长，什么都要管。Compositor只做该做的事情，把上面的过程简化成任务便是：
基于Wayland协议，处理evdev的信息； 通知Client（即应用程序）对相关事件做出反应（至于应用程序想怎么反应，Compositor不需要过问）； 收到Client的状态更新，重新合成图形或管理新的图形布局。 你意识到了，Wayland Compositor的角色，就像是“X Server”+“Window Manager”，但它只做份内的事情而已。我想你已经可以想像Wayland构架是如何简单而且高效了，它一举解决了“X Window”发展这么多年来积累的、通过“扩展”去解决的那些问题。