X的瓶颈究竟在那的一点猜测，欢迎讨论
X比Windows执行要慢，很多人都归咎于一个是运行在普通用户级，一个运行在内核级。除此之外，我认为还有一个问题，就是X本身体系的问题。例如使用gtk创建一个button。完成一个按健处理在X下可能就是这样。
1 mouse移入button的窗口区，按下左键。一个中断发到内核。
2 内核把处理交到X服务器，发生了一次进程切换。
3 X服务器进行一些判断处理，通过socket发送一个事件给X客户程序，进程切换。
4 X客户程序接收事件，发出绘制按钮按下的样子的绘图指令，进程切换。
由上面，仅仅按一下mouse按钮，为了处理一个button被按下的样子，总共发生了3次进程切换。同样的，例如实现cursor移入某些控件时加亮的处理，也要进行类似的三次进程切换。由于linux是一个分时系统，并不一定会因为突发事件而迅速切换到相应的处理进程去，因此，在上面这个过程中，使用者就能感觉到X下桌面程序有种不明显的滞后感，而没有使用WINDOWS时的那种顺畅感。
欢迎大家指正。 有同感,在X下,点击后,与WIN下比较,总觉得会慢一点 你用的是gtk
你直接用X试试
一点都不慢 你用的是gtk
你直接用X试试
一点都不慢
我只是为了说明一个带有动画效果的button内部是如何消耗资源的，说gtk只不过是个例子而已。
呵呵，不知道你说的直接用X是什么意思，我不知道那个不是最终发的X指令？或者你想告诉我TWM没有什么画面效果，所以快？亦或者你要说高手是不用gtk，qt的，直接用xlib？ 有没有人想过要改进Ｘ呢？ 既然是C/S模式，可否让Client直接来处理用户界面（如鼠标，键盘，绘图），让Client于server和kernel的交互很少，client和sever甚至kernel根本就不交换与鼠标和键盘有关的事,server/kernel只响应client的事务请求，这样不可以么？
Re: X的瓶颈究竟在那的一点猜测，欢迎讨论
X比Windows执行要慢，很多人都归咎于一个是运行在普通用户级，一个运行在内核级。除此之外，我认为还有一个问题，就是X本身体系的问题。例如使用gtk创建一个button。完成一个按健处理在X下可能就是这样。
1 mouse移入button的窗口区，按下左键。一个中断发到内核。
2 内核把处理交到X服务器，发生了一次进程切换。
3 X服务器进行一些判断处理，通过socket发送一个事件给X客户程序，进程切换。
4 X客户程序接收事件，发出绘制按钮按下的样子的绘图指令，进程切换。
由上面，仅仅按一下mouse按钮，为了处理一个button被按下的样子，总共发生了3次进程切换。同样的，例如实现cursor移入某些控件时加亮的处理，也要进行类似的三次进程切换。由于linux是一个分时系统，并不一定会因为突发事件而迅速切换到相应的处理进程去，因此，在上面这个过程中，使用者就能感觉到X下桌面程序有种不明显的滞后感，而没有使用WINDOWS时的那种顺畅感。
欢迎大家指正。
X是靠网络协议通讯的，通过X server与X client的通讯还有一个编码解码的过程。
发事件给客户端是一次编码解码,按钮按下的绘图可能就不止一次编码解码的过程了。 听说 x-window在开发的时候是想让x本身做到与硬件没有关系……
不知道这是不是一个原因呢？ 我觉得unix－linux的话可以考虑试试看， :-) xWindows本来是分布式的(C/S),如果Client与server不在同一台机器上，用户界面处理都完全是由Client机器处理，与linux本身没有关系
如果Client与server在同一台机器上，用户界面处理必须由linux处理，所以性能上会有影响，
页:
[1]