基于wayland的linux桌面,揭开Wayland的面纱 - iTech - 博客园

揭开Wayland的面纱 - iTech - 博客园

(2011-11-30 22:38:22)

标签：

锦衣夜行

娱乐

如果在两年前,按照那篇《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的架构图中,最显著的一些特点是:

它复用了所有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"发展这么多年来积累的、通过"扩展"去解决的那些问题.

看似很美好,那么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绘制,但一直不彻底).

这意味着两点:

GTK+的一直以来评价不怎么样的跨平台性,在3.0将有显著的突破;

GTK+的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,几点说明:

支持透明、阴影和简单的窗口管理;

所有的图形绘制,都是通过Cairo-gl(Cairo的OpenGL后端)进行;

这是又一个例子,我编译了Clutter的Wayland后端,锦衣夜行,成功地跑起了一个Clutter的Demo:即同中Ubuntu

Tweak的3D Logo.

除了这个Wayland Compositor本身是跑在X

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

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

简单的说,它就是一个去除X

Window中不必要的设计、充分利用现代Linux内核图形技术的一个显示机制,它的出现是自然而然的,www.wuliuxs.com,它的使命不是为了消灭X

Window,而是将Linux的图形技术发挥至更高的一个境界.传统的X Window(即经典X应用、Gtk

1.x/2.x等旧应用),也会在相当长一段时间内得到继续支持,通过Wayland Client的形式跑在Wayland

Compositor上,直到最终升级、取代或被淘汰.

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

完!

Kristian Shows Off GTK+ 3.0 On Wayland 新版博问上线,帮您解决IT难题

三星很陶醉:爷会成为智能手机之王 Lights:奇妙的WebGL 3D体验 Engine Yard增加对Node.js的支持

GiMP帮助发现年轻达芬奇的自画像 移动平台:开放与封闭 我为什么向后端工程师推荐Node.js

高德纳(Knuth)谈计算机程序设计艺术(上) 整洁的代码 VS 卓越的代码 浅谈 HTML5 的DOM Storage 机制

更多知识库文章... China-pub 2011秋季教材巡展 China-Pub 计算机绝版图书按需印刷服务 Cpp/CLI编程宝典

[Cpp写好函数和类] Autodesk(2) BuildRelease(108) BuildTools(76) C++/CLI(7)

C++Tools(14) knowledge(1) OtherLanguage(5) Python(78) 批处理/Shell(33)

2011年11月(27) 2011年10月(7) 2011年9月(17) 2011年8月(42) 2011年7月(16)

2011年6月(15) 2011年5月(5) 2011年4月(11) 2011年3月(16) 2011年2月(22)

2011年1月(31) 2010年12月(13) 2010年11月(14) 2010年10月(9) 2010年9月(7)

2010年8月(5) 2010年7月(22) 2010年6月(17) 2010年5月(9) 2010年4月(7) 2010年3月(6)

2010年2月(11) 2010年1月(4) 2009年12月(9) 2009年11月(6) 2009年10月(5)

2009年9月(19) 2009年8月(27) 2009年7月(4) 2009年6月(1) 2009年5月(12)

2009年4月(9) 2009年3月(2) 2009年2月(8) 2009年1月(7) 2008年12月(1)

guidesignstudio live.sysinternals.com nirsoft.net

unxutils.sourceforge.net win2000.microsoft.com

win2003.microsoft.com backtrack-linux.org chinaunix.net

distrowatch.com howtoforge.com linux blog linuxany.com

linuxdiyf.com linuxsir.org linuxtone.org linuxtopia.org

linuxtoy.org linux-tutorial.info litrin.net rpmfind.net

tinycorelinux.com ubuntu.org.cn unix-center.net yolinux.com

codeproject.com commandwindows.com computerperformance.co.uk

csharp.net c-sharpcorner.com developer.com dotnetslackers.com

effectiveCpp.cppblog functionx.com python.org robvanderwoude.com

visualc.msdn.com w3schools.com 51cnnet.net coderun.com

connectionstrings.com csharpsearch.com freebyte.com gotapi.com

interop123.com interopsystems.com itboba.com net.classes pdfchm.com

pinvoke.net PythonCodeSearch regexlib.com sooset.com

sorting-algorithms.com sourcemaking.com techtarget.com.cn

thefreecountry.com tutorialspoint.com virtuatopia.com agiledon.com

asp.net debugging blogs.vmware.com cnblogs.com.stbchina csharp3and4

dbanotes.net DotNetDebugging dotnetperls.com

frameworkdesignguidelines frameworkdesignguidelines2 Pythonexample

technetscript voidnish.com aosabook.org apache.org cfx.codeplex.com

code.google.com codeplex.com csharp-source.net mozilla.org

ogre3d.org orchardproject.net silk.codeplex sourceforge.net

1code.microsoft.com channel9.msdn.com downloads.microsoft.com

forums.microsoft.com interoperabilitybridges.com

microsoft.com.chopsticks microsoft.com.web microsoftpdc.com

msdn.magazine msdn.microsoft.com netframeworkcenter

windowsclient.net 我的sharpdownloadsdk gamedev.net nehe.gamedev.net

osdata.com reactos.org businessweek.com cnbeta.com diggsoft.com

inezha.com itxinwen.com kekenet.com sl.iciba.com speak2me.cn

testing.hj.com xiaohuawang.org

分享：

喜欢

0

赠金笔

加载中，请稍候......

评论加载中，请稍候...

发评论

登录名： 密码： 找回密码 注册记住登录状态

昵   称：

评论并转载此博文

发评论

以上网友发言只代表其个人观点，不代表新浪网的观点或立场。