有关GUI

发布于 2008-09-01 17:35:19 浏览：14135 订阅该版

19 个回答

bernard 2008-09-01

这家伙很懒，什么也没写！

hqbvqv 2008-09-02

这家伙很懒，什么也没写！

bernard 2008-09-02

这家伙很懒，什么也没写！

shaolin 2008-09-03

这家伙很懒，什么也没写！

bernard 2008-09-04

这家伙很懒，什么也没写！

bernard 2008-09-04

这家伙很懒，什么也没写！

nxin>
有没有这样的GUI：只有顶级窗口由系统集中管理，系统的消息分发也只到顶级窗口，顶级窗口的合成用硬件实现(opengl)，每个顶级窗口对应一个缓冲区，可以直接写屏；子窗口由应用自己管理（创建、销毁、裁减、消息分发等），这样不同应用的窗口更新互不影响，不需要同步，而一个应用内部的窗口更新需要同步，但是在一个进程之内，即使支持多线程，也可以做得效率很高。

gogoliu>
先更正一下各位的观点： 
1）从不同桌面环境的快慢程度来看，某桌面环境慢是该桌面环境设计的问题，跟X Window关系不大 
2）DirectFB的多进程模式是通过内核fashion机制实现的，不是在共享库中实现的

要实现多窗口系统，各窗口之间必须能相互感知，这样就必须能得知各窗口的几何信息。因此： 
1)单任务中实现多窗口系统无需通过内核或IPC让各窗口之间相互感知，程序内部实现即可，这部分实现也可抽象为一个共享库。 
2)多线程中实现多窗口系统也无需通过内核或IPC让各窗口之间相互感知，因为多线程最简单快捷的通信方式是全局变量，因此同样的多线程的实现也可以抽象为一个共享库。 
（minigui的单任务和多线程版本之所以能以库的形式提供，现在大家知道答案了。） 
3)多进程中实现多窗口系统需要通过内核或IPC让各窗口之间相互感知，内核就像同一进程中多个线程的全局变量一样可被系统内进程访问。 
4)分布式系统中实现多窗口系统需要通过socket实现。

上述4种不同的设计，后者的方法能用于前者，反之则不行；而越往后的实现手段性能越差。X Window开始设计时是属于分布式系统的一部分的，所以采用socket实现各窗口之间相互感知。而由于采用socket的兼容性最大，所以X默认并没有采用更快的IPC手段，更没有把X Server放入内核（虽然X server带有显示芯片驱动）。当然X Server没有放入内核还因为Unix系统最早并不支持图形显示设备、Unix的硬件平台太多显示子系统各不相同、Unix中的设备通常都是单进程访问的。

任何IPC必须经过进程切换和系统调用，所以对比而言确实比把窗口系统置入内核慢。如果提高X Server的优先级，则有更快的速度接收到IPC信息并处理，这是几年前linux 2.4时代使用的方法，后来因为在进程调度和切换方面做了工作，这个方法不用了。 
另外，X中窗口剪切域由X Server管理，所以X Client会把窗口的绘制指令发到X Server，X Server进行剪切后再调用内部的显示驱动绘制要显示在屏幕的部分。如果X Client拥有窗口剪切域，那么它可以完成剪切域计算，可提高计算并行性，也可以减少绘制指令的发送。但会出现一个问题，如果X Server不做剪切运算的话X Client可以随意绘制，这样屏幕可能就会被Bad Client弄花。 
另，X Client必须通过X Server访问显示设备也会加长访问显示设备的路径，降低性能。 
如想获得高性能，把窗口管理功能和图形功能放入内核确实是最好的选择了。

上面nxin提的设计确实可行，但如果你没有如窗口半透、阴影的需求，采用窗口剪切域来实现多窗口是最好的。因为采用窗口剪切域你只需要屏幕缓存那么大的显存，而采用你的设计，那消耗的显存是相当大的，Mac OS X推出时消耗内存大跟这点不无关系。在20世纪PC的显示硬件根本无法支撑你的这种设计，（我猜测）windows也是在xp推出时才采用你这样的设计，但它没像OS X那样采用3D合成各个窗口。而且即使采用了你的这种设计，窗口剪切域依然有用。

easion>
nxin讲的并没有什么特别明显的好处，因为你子窗口内也需要实现剪切域管理，只是该谁来计算的问题。 
nano-x有一个非常优秀的设计：当建立用户程序创建窗口的消息传到窗口管理器程序的时候，窗口管理器（根据增加标题栏和边框）来计算他的大小，之后创建一个新的窗体，最后调用GrReparentWindow,使用户程序创建的窗口成为他的一部分(子窗口)，这样当你移动标题栏的时候，消息被分发到窗口管理器；当你在这个窗体内移动鼠标的时候，消息被分发到用户程序。 
我猜x window窗口管理器的实现可能也大概如此吧，这样是不是非常灵活呢？ 
用户程序最好不要直接写屏幕，在多进程情况下，写屏过程中互斥的设计令人痛苦。

bernard 2008-09-04

这家伙很懒，什么也没写！

bernard 2008-09-04

这家伙很懒，什么也没写！

RTGUI>
如果要在子窗口内实现自己的剪切域管理，那么一些事件（特别是鼠标事件是和位置直接相关的）得先传到窗口，然后再一级级派发到相应的子窗口。而如果子窗口剪切域在server端实现，那么server就可以直接定位到子窗口一级。

在RTGUI中，子窗口的剪切域是由窗口自己管理的，所以事件也得这样一级级派发。针对于鼠标事件，如果client要监控鼠标移动，这可真是一个头大的问题：所有的鼠标移动事件都经由server->window->widget这样的路线传递（widget就类似于X中的子窗口），一下子通信量就上去了。所以现在的做法是，需要监控鼠标移动事件的窗口需要在server进行登记，由server决定是否发送鼠标移动事件，这个也算是子窗口自己管理剪切域的一个补充。

从设计的角度来说，因为RTGUI提倡使用panel（一个屏幕上互不相重叠的区域，这一块块区域（panel）也可以看成是一个特殊的window），所以把剪切域管理放到了client，应该会减少不少的计算量及通信量。

RTGUI的实现是窗口剪切域完全由client管理，因为绘图也放在了client，所以它只允许在自己的可视范围内进行绘图操作。server只保留各个window的位置信息，如果window发生变化（创建，消失，移动，更改大小等），会把剪切信息（外剪切）发送给各个相应的window（按照Z序的顺序发送，只发送window上层的剪切信息）。把绘图放在client的缺点就是要实现alpha绘图比较麻烦，如果只是绘到buffer 缓冲，那占用的内存就比较大了。现在想到的办法是：client alpha->发送刷新的消息->server->通知底层覆盖的window进行更新；当底层window更新完成后，server->发送允许绘图->client alpha进行alpha绘图。只是这样时序得严格要求，否则出现了同步问题，很快就花屏。

RTGUI>
>>上面nxin提的设计确实可行，但如果你没有如窗口半透、阴影的需求，采用窗口剪切域来实现多窗口是最好的。因为采用窗口剪切域你只需要屏幕缓存那么大的显存，而采用你的设计，那消耗的显存是相当大的，Mac OS X推出时消耗内存大跟这点不无关系。在20世纪PC的显示硬件根本无法支撑你的这种设计，（我猜测）windows也是在xp推出时才采用你这样的设计，但它没像OS X那样采用3D合成各个窗口。而且即使采用了你的这种设计，窗口剪切域依然有用。

采用窗口剪切域需要缓存屏幕大小的缓存？窗口自己管理剪切域后，就可以直接写屏了，不用缓存的。 RTGUI的实现中，一个window可以保留自己窗口大小的缓存，也可以直接采用直接写屏的方式。只是窗口透明这些特效，我想了半天还只是想出一个蹩脚的方法。在RTGUI中，一个panel可对应于一个主程序（workbench），然后一个workbench上可放置多个view，如果只在workbench上实现一些特效倒是容易，所以以后有打算把view通过3D特效的方式展示出来。而window的特效，有些黔驴技穷了。。。