X的瓶颈究竟在那的一点猜测，欢迎讨论

kakuyou

X比Windows执行要慢，很多人都归咎于一个是运行在普通用户级，一个运行在内核级。除此之外，我认为还有一个问题，就是X本身体系的问题。

例如使用gtk创建一个button。完成一个按健处理在X下可能就是这样。

1 mouse移入button的窗口区，按下左键。一个中断发到内核。
2 内核把处理交到X服务器，发生了一次进程切换。
3 X服务器进行一些判断处理，通过socket发送一个事件给X客户程序，进程切换。
4 X客户程序接收事件，发出绘制按钮按下的样子的绘图指令，进程切换。

由上面，仅仅按一下mouse按钮，为了处理一个button被按下的样子，总共发生了3次进程切换。同样的，例如实现cursor移入某些控件时加亮的处理，也要进行类似的三次进程切换。由于linux是一个分时系统，并不一定会因为突发事件而迅速切换到相应的处理进程去，因此，在上面这个过程中，使用者就能感觉到X下桌面程序有种不明显的滞后感，而没有使用WINDOWS时的那种顺畅感。

欢迎大家指正。

gradetwo

没有感觉哦，好像差不多！

5417

不过，Windows也需要类似的过程把。

crquan

最初由 kakuyou 发表
1 mouse移入button的窗口区，按下左键。一个中断发到内核。
2 内核把处理交到X服务器，发生了一次进程切换。
3 X服务器进行一些判断处理，通过socket发送一个事件给X客户程序，进程切换。
4 X客户程序接收事件，发出绘制按钮按下的样子的绘图指令，进程切换。

如果XServer与XClient是在同一机器上（大多数人都如此）
则不使用 TCP/IP socket,
而是 UNIX Domain socket, 也就是直过类型的，省略此进程切换。

zxb

mouse都要中断才可以正常工作。Windows下也一样。
之后就是中断处理（当然是内核的事了），然后内核把mouse消息传到上层相应的进程 中，在windows当然也是这样的。
不过不能的是windows的图形界面是集成到内核中，所以这个可以比X少了很多中间开销。
现在Fedora2的X.org性能有很大的改进。Fedora3没有用过。
你可以下载一个试试

xsinuz

不知道Win32下面是怎么处理的，如果让内核直接和应用程序交互，那么
1、鼠标中断，上下文切换，到内核空间执行处理，生成X事件，加入到UI事件队列中。
2、上下文切换，回到用户空间(如果这个程序还有时间)，应用程序得到事件，并处理。
好像过程简化了。但内核的负担就重了，由于内核可以看作但进程的，太多地IO操作要他来实现，这样响应的速率快了，机器的性能是不是会下降。