揭开Wayland的面纱(二):Wayland应运而生

来源:http://www.linuxgraphics.cn/xwindow/wayland_intro_2.html

作者: TualatriX
日期: 2011-01-10
本文详细介绍了 Wayland。

引入

话说在上篇(揭开Wayland的面纱(一):X Window的前生今世)中我介绍了一些X Window的历史及发展,还没有提到Wayland本身,不少人已经等不及了。不过,介绍这些是有必要的,毕竟要知道X Window的一些知识,才能明白为什么会有Wayland这个东西。

在本篇正式开始介绍Wayland之前,让我们先回到2008年11月4日,也就是整整两年前,我当时在中文领域第一时间报道了“Wayland”的新闻:Wayland:Linux的新X Server,在其后的一个月,又写了:Wayland最新动态

当时这两篇文章主要是翻译Phoronix的新闻,自己也没有亲自把玩过Wayland,再加上Wayland项目还处于比较初期的阶段,对其的理 解有限。如今经过整整两年的开发,包括Linux内核在图形方面的不断的改进、GTK+图形库的不断进化,Wayland已经渐渐成熟,接近可用状态。

那么,回到上篇开头最初的那个问题:

Wayland究竟是什么?

如果在两年前,按照那篇《Wayland:Linux的新X Server》的理解,它是一个新的“X Server”,在于改善当前X Server的不足,从而取代它。现在,我们已经可以用更标准的语言来定义Wayland了,那就是:A Simple Display Server。

没错,Wayland是一个简单的“显示服务器”(Display Server),与X Window属于同一级的事物,而不是仅仅作为X Window下X Server的替代(注:X Window下分X Server和X Client)。也就是说,Wayland不仅仅是要完全取代X Window,而且它将颠覆Linux桌面上X Client/X Server的概念,以后将没有所谓的“X Client”了,而是“Wayland Client”。

更确切的说,Wayland只是一个协议(Protocol),就像X Window当前的协议——X11一样,它只定义了如何与内核通讯、如何与Client通讯,具体的策略,依然是交给开发者自己。所以Wayland依然是贯彻“提供机制,而非策略”的Unix程序。

“什么?Wayland还是Server/Client模式?”可以这么理解,但实际上与X Window的Server/Client有着本质的区别。

让我们用一张类似前文所示的图表来重新演示一下,在Wayland的框架下,窗口事件的响应是如何进行的。

在Wayland的架构图中,最显著的一些特点是:

  1. 它复用了所有Linux内核的图形、输入输出技术:KMS、evdev,因此已支持的驱动可以直接拿来用;
  2. Wayland没有传统的Server/Client的模式,取而代之的是:Compositor/Client,这不仅仅是换一个名称而已,后面会讲到具体区别;

还记得前文中“点击Firefox的刷新按钮”这个应用场景吧?在Wayland里,所有的流程是这样的:

  1. 内核收到了鼠标发出的信息,经过处理后转发到了Wayland Compositor,就像之前发往X Server一样。
  2. Compositor收到消息后,立马能知道哪个窗口该收到这个消息,因为它就是总控制中心,它掌握窗口的层级关系、动画效果,因此它知道该坐标产生的鼠标点击信息应该发送给谁,就这样,Compositor将鼠标的点击信息发送给了Firefox。
  3. Firefox收到了消息,这时如果是在X Window下的话,Firefox会向X Server请求绘制按钮被按下的效果。然而在Wayland里,Firefox可以自行进行绘制而不需要再请求Compositor的许可!这就是传说 中的:直接渲染机制(Direct Render)!Wayland不管Client的绘制工作,整个过程变得十分简单而且高效!当Firefox自行完成了按钮状态的绘制后,它只需要通知 Compositor,某块区域已经被更新了。
  4. Compositor收到Firefox发来的信息的,再重新合成那块更新的那块区域,将最终桌面效果呈现给用户。这个过程主要是跟内核、显卡驱动打交道了。

整个流程是不是很自然、很简单?

所以结论出来了:

  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的角色,就像是“X Server”+“Window Manager”,但它只做份内的事情而已。我想你已经可以想像Wayland构架是如何简单而且高效了,它一举解决了“X Window”发展这么多年来积累的、通过“扩展”去解决的那些问题。

看似很美好,那么Wayland现在的可用性如何?大家都知道,GTK+、Qt,现在都是基于X的,它们能顺利地移植至基于Wayland吗?当然可以!

逐渐成熟的Wayland周边应用

还记得前面那篇文章中,我说过的这句话吧:“尽管在Linux平台下,Cairo、Pango的发挥依然是基于X Window的,但X Window充其量仅仅是一个“backend”而已,并不是少它不行。同理,跨平台的GTK+、Qt也只是视X为其中所支持的后端之一,假如哪天X真的 不在了,更换一个新后端,当前的GNOME、KDE也能完整的跑起来。”

你已经想到了,GTK+、Qt,只需要简单的处理一下后端,便可以跑在Wayland上了。比如:

在当前的GTK+3.0开发分支中,有一个开发分支是“rendering-cleanup”。“清理渲染”?这是做什么的?联想一下那个连Client“怎么渲染”都要管的X Server吧。

对了!GTK+3.0已经彻底移除了所有图形渲染、绘图方面跟X相关的部分了,现在它是一个100%基于Cairo绘制的图形工具库了(之前GTK+2.x时在2.8开始逐渐转向用Cairo绘制,但一直不彻底)。

这意味着两点:

  1. GTK+的一直以来评价不怎么样的跨平台性,在3.0将有显著的突破;
  2. GTK+的Wayland后端,已经在路上了!

GTK+跑在Wayland上,截图引自:Kristian Shows Off GTK+ 3.0 On Wayland

当然,Qt也有了,限于篇福,这里就不介绍了。

另外一个已经在主开发分支便支持Wayland的东西便是:Clutter。这是一个基于OpenGL的动画框架,我以前介绍过很多次的GNOME Shell、Moblin, 都是基于Clutter的。在Clutter当前1.5.x的开发分支,Wayland作为其中一个“backend”,已经得到了 “experimental”的支持。所以说,GNOME 3.0、MeeGo Netbook很可能会成为第一个应用Wayland的桌面环境。

那么,看来Wayland真的触手可及了啰?可以这么说,但是还差一点。

Wayland技术实现及工作重点

Wayland的核心协议已经实现的差不多了,它充分利用了Linux内核的KMS、GEM、DRM等技术,另外,它默认是支持3D加速的,也就是通过OpenGL ES进行图形的合成——光是这一点,X Window又要泪奔了。

使用OpenGL ES这个子集而非OpenGL,这意味着什么?想想有多少项目是用OpenGL ES的:Android、iOS、WebOS、WebGL……几乎所有主流的的移动操作系统、浏览器3D的实现,都选用了精简、高效的OpenGL ES。

我不知道当前Android的Display Server、Input/Output是如何实现的,总之跟iOS相比,在触控的响应上是有差距的。未来,对OpenGL ES有着良好支持的Wayland,不知道会不会给这些基于Linux内核的移动操作系统发力呢?我想是非常有可能的!

这时问题就来了,因为Wayland所使用的,都是当前Linux下最新潮的图形技术。所以理所当然的,在驱动这一层面会有一些厂商跟不上。

拿nVIDIA开刷吧,KMS技术都出来一年多了,Intel的全部显卡和AMD部分显卡已经获得支持了,可nVIDIA压根就没有兴趣搞这个,以 致于开源社区利用反向工程,通过“Nouveau”项目让nVIDIA支持了KMS,当然比较遗憾的是,性能跟官方闭源的驱动是差了相当的距离。

所以说,基于Wayland的Linux桌面/移动要真正得到应用,驱动这一关是一定要解决的。不过正所谓潮流不可档,nVIDIA迟早会支持这项技术的。

等到驱动完全不成问题了,Wayland还需要一个全功能的“Compositor”,这个角色,就由Clutter/Mutter、 Compiz、KWin等当前主流的窗口管理器来扮演的,相信只要通过简单的修改,这些合成窗口管理器很快地就能转变成一个全能的“Wayland Compositor”!

把玩Wayland及展望未来

讲了这么多技术、历史和业界,大家肯定枯燥了,究竟现在有没有可以跑的“Wayland Compositor”可以玩玩呢?当然!

现在,只要你从官方取得源码,然后根据教程进行编译,就能跑起一个简单实现的“Wayland Compositor”。由于Wayland协议的灵活性,Wayland Compositor也可以拥有自己的后端:比如直接在DRM上跑Wayland(不需要X),或者在X Window上跑起一个Wayland Compositor(相当于在X Window上用Xephyr再跑一个X Window)。

当前我在Ubuntu 10.10的图形环境下,就跑起了默认的这个简易的Wayland Compositor,几点说明:

  1. 支持透明、阴影和简单的窗口管理;
  2. 所有的图形绘制,都是通过Cairo-gl(Cairo的OpenGL后端)进行;

这是又一个例子,我编译了Clutter的Wayland后端,成功地跑起了一个Clutter的Demo:即同中Ubuntu Tweak的3D Logo。

除了这个Wayland Compositor本身是跑在X Window之上,其本身合成效果、处理窗口布局等等,都完全没有用到X,而且整个代码非常简洁。未来的Linux图形,就会像是这样一个结构简单又高效的样子。

相信看完我这些介绍,大家对Wayland是个什么角色,已经比较清楚了吧?

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

2011年后期或2012年,我们将能看到Wayland正式着陆,期待吧!

对本文的一个评论

ezjd

下面是几点不同意见:

  1. 虽然传统的X应用需要X server作所有的drawing,现在的GUI toolkit实际上都自己作render到offscreen buffer上,再利用Window manager/Compositor去显示到framebuffer,所以运行在本地的时候,和Wayland的方式没有太大不同,因此也不会有太大的性能提升,当然,wayland 把compositor加入核心,结构上有了改进,因此也会有改善。
  2. 很多人能过分强调X的socket的overhead,但是即使是在低端的嵌入式系统,也只有增加了小于5%的CPU,也许是因为上面提到的改进。
  3. 没有听说有人正在把Wayland porting 到Windows 或 MAC OS,因此它也不会帮助GTK+改进跨平台的问题。
  4. 个人认为Wayland不会取代X,因为network transparent 在很多环境下还是很重要的。
  5. 目前不知道Wayland和其它Compositor如何分工,因为比如clutter下主要是clutter完成compositing。
  6. GUI toolkit只是UI 的一部分,桌面系统GNOME 和 KDE都还是依赖X,甚至KWin都依赖X,compiz直到最近的0.9才基本分离出X的模块。
  7. 顺便说一下,linux主流的基于X的UI系统都已经用了OpenGL,甚至Maemo 5,MeeGo都要求必须有OpenGL ES的支持。
SotongDJ 回复 ezjd

回ezjd的意见(以下是我的看法,不要误会我的意思,只是回你罢了):

  1. 没意见
  2. 同样没意见
  3. 作者的意思是因为去除与X windows相关的部分,所以已经消除对X Windows的依赖性,这点对跨平台很有帮助。
  4. 的确,需求还是有的,但在家用电脑上的需求可说是无,所以为了可能会有这种局面:伺服版的发行版是用X Windows,而其他版本(如家用版和上网本版等等)则是用Wayland
  5. Wayland只是个Protocol,其Compositor是哪一种需视用户(或发行版的作者)如何设定
  6. 基本上我没意见

你可能感兴趣的:(wa)