I have set up many systems that dual boot windows and linux, in my experience, the GUI on the linux side is always much slower.
I found this post on the ubuntu forums, it explains some of the fundamental problems with the X11 architecture. It also cites a white paper which provide more detail.
404error wrote on the 13 Feb 09 at 01:52
I think that there has been a knee-jerk reaction to the original suggestion that is not necessarily founded on solid reasoning. Such a reaction is understandable, as a large, reasonably-functional piece of software should not simply be discarded without very strong motivation. And while the original post was well-intentioned, I do believe it could provide stronger arguments. While I have only modest experience programming directly in X11, I will do my best to explain why I also feel X11 should be replaced. If anyone has evidence that contradicts the following opinions, I would be most interested.
To go directly to the point, I think that the "linux desktop" needs a small, fast, fully-featured graphical backend. This backend should provide basic drawing primitives, input device event handling, network transparency, but should not involve itself with higher-level graphical interface design (like buttons and menus). So far, I suspect that most of the above posters would agree with this notion. Here is where we diverge: I do not think that X11 is small, fast, or fully-featured. And I think that there are fundamental aspects of the X11 protocol which will prevent any implementation from working well.
The first fundamental problem is that X11 is implemented using an asynchronous model. In other words, to raise a window one cannot simply call XMapWindow to map a window. One must call XMapWindow, which will transmit that command to the server, then one waits for the server to respond with a MapNotify event, and then one can proceed. When running over a network this potentially allows the client to send off multiple commands before waiting for the response to a single command, allowing improved performance. But when run on the local machine, this requires a great deal of round-trip communication that produces latency that causes many users to perceive X11 programs as "slow." This problem has been reduced somewhat through the use of shared memory, but still hinders performance. The asynchronous model was an excellent decision for the 1980s when most programs ran over the network. But in the current day, the backend is optimized for a use-case that is rarely used.
Beyond performance issues, the asynchronous model is also the root cause of much of the flickering that occurs on the desktop. As widgets are moved around, the asynchronous model causes repaints to occur while the windows are still in flux resulting in flickering. The developers at QT have effectively already abandoned X11 (or at least a good part of the design) by moving all of the event handling into the QT library to circumvent this flickering (see http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all- flicker).
A second fundamental problem with X11 is the absence of resolution independence. X11 describes all coordinates using integers that represent pixel positions. As screen sizes change and pixels become smaller (or less likely larger), then the display begins to appear pixelated. In a resolution independent scheme, all coordinates are described using floating-point values so that display is rendered correctly regardless of the screen size. Again, going with integers positions was an excellent design decision for the 1980s but is no longer an effective design. In the 1980s many of machines shipped without a math co-processor, so that floating-point operations were much much slower than integer operations and the quality of the graphical output was arguably less important. Today, virtually any modern processor has a math co-processor that can perform multiple floating-point operations per clock cycle. The difference in performance that would result from the use of integers rather than floating-point values is gone, the only thing that remains is the pixelation.
The last main problem with X11 is the profound lack of functionality. Some of the above posters have claimed that now that X11 has compositing it has pretty much everything quartz has. To be blunt, this is very very far from the truth. Competing graphical backends (e.g., Quartz) provide much stronger support for anti-aliased drawing (not just text but lines and polygons), gradients, transforms, shadows, patterns, transparency, font selection, color spaces, and data output (to screen, PDF, or Postscript). Modern linux programs compensate for the inadequacies of the X11 protocol by performing this rendering within the toolkit. GTK uses cairo for rendering while QT uses their own engine. This works but not particularly well. Implementing such functionality in the toolkit requires a fair amount of server-client communication and makes poor use of 2D hardware acceleration. Both carry performance
There are a number of other issues that are fundamental to the X11 protocol, which cannot simply be fixed by "enhancing" the current work. Without belaboring the point I'll simply cite a paper on the topic: http://www.std.org/~msm/common/WhyX.pdf
I would also like to respond to some of the points made above regarding the feasibility of such a project. Some of the posts suggest that this would require a huge amount of work because so many programs use X11. I'm not sure these fears are well-founded as actually very very few programs directly use X11. Most programs are written using GTK, QT, wxWidgets, FLTK, or some other higher-level toolkit. All of these toolkits already support multiple backends, and so support for the new graphical backend would likely just require modification of a few libraries and those miscellaneous programs that require direct use of X11 (window managers, login managers, etc). Backwards compatibility is not as hard as it would seem either. One would simply have to produce a driver for Xorg that would paint onto a drawable of the new backend rather than to the screen itself. If I'm not mistaken, this is how Apple implemented X11 without expending too much effort. The task of implementing the new backend itself is non-trivial but far from impossible. Open-source code for rendering is already available and most of the video drivers could be re-used. This is not a certainly not a one-man project, but it is achievable.
To conclude, I think what I want is what the same as what many of the above posts also want. I want a small, fast, fully-functional, network-transparent graphical backend that implements only rendering routines and not high-level interface. I want something that can compete with Quartz. I just don't think X11 is it or ever will be it.
http://brainstorm.ubuntu.com/idea/16346/
