It is a popular opinion that X11 is reaching the end of it's useful lifespan. Whether that is true or not there have been several projects aimed at replacing or extending X11 and many rants written on the subject. What I intend these pages to have is a technical unbiased overview of exactly what X11 got right and wrong along with supporting technical information. An attempt is made to steer clear of obviously irrelevant issues such as terminology, only the technology and it's implications will be considered. Take what you will from these pages, they can be interpreted as a summary of the problems facing window systems today, or as a call to arms to create something better.
Before going into what is wrong with X, we should examine what X got right. Many efforts (plagued by NIH syndrome) do not take the time to fully understand current state of the art before they decide X sucks and start reimplementing code. While this is fine for learning and exploring, pragmatically one cannot expect to replace something they do not fully understand. In addition, it is my belief that X is not a horrible system. It is powerful and the decisions made are justified given their context Most of the problems are things which were not considered at the time of its development or are bugs which one can expect in any complicated system, including any replacement system one might propose.
X has elegant and powerful extensibility features. They allow apps to be written which can run efficiently on the newest and greatest servers down to lowly minimally compliant ones. Many of the concerns raised in this document have been addressed in extensions. It is plausible that all concerns (except perhaps the bloat one below) can be addressed in a future extension. Any system which replaces X must be as easily extendable, it would be pure hubris to assume one got everything right the first time around.
More so, X allows arbitrary windows to mix and match in arbitrary ways independent of the application which is running them or even what computer they are running on. This has traditionally not been taken advantage of as much as it could be. This was mainly due to no standard way to negotiate things like size constraints between the parent and child windows. XEmbed solves this problem.
This decision made perfect sense when X was created. Many different computer languages were duking it out for top dog and inter-language calling and shared libraries were not common. in order for programs to talk to each other they needed a language defined for them to speak over byte-streams such as pipes, the network or whatever the OS provided. It made to let anything that spoke the protocol to be X compliant, standardizing an API was a one-shot deal only useful for a single language. with the advent of shared libraries and most languages being able to call C directly, suddenly XLib, the sample C library provided along with X as an example of how one might call X from C became what people began to think of as X. shared libraries and more and more functionality being placed in XLib made API compatibility even more important.
Wouldn't it be nice to run a new window manager in some subwindow, just to try it out? or imagine an application that starts an arbitrary window manager to deal with its subwindows. The root window is distinguished and special in X, in order to have apps use another window, several concerns need to be addressed. they are detailed in this paper
unfortunately, the quite useful ability to display and interact with applications running on another computer has a fatal flaw. You must trust all applications which attach to your desktop since they may perform malicious activity, from pretending to be a password dialog to sending fake key-presses to your terminal window with commands to erase your system. Although it is pure speculation on my part, if this were in the system from the start, the Internet would look very different today. Instead of viewing web pages, you might be running remote X apps to interact with servers. If your friend wanted to show you something, they could just have their web browser pop up a copy of its view on your system (with the help of xmove or an xprotocol replication program). Some work was done on this in the BROADWAY project at the X consortium. unfortunately, it was too little too late, however it's design will be important to study when developing a new window system. The SECURITY extension is what allows untrusted apps to run.
The absence of this feature is probably why many people seem okay with dropping the network transparency aspect of X11, if people could throw views of arbitrary applications back and forth simply and securely and run complicated UI apps remotely from untrusted sites then they would realize the minimal price for network transparency is worth it.
The various unappealing effects of drawing to the screen are usually referred to as flicker. The style of X programming encouraged by the protocol is particularly subject to these artifacts. While there are workarounds to minimize the visual artifacts, the original latency is still present before a user may see the contents of a new window. This causes the classic X problem with pop-up windows that lag behind the mouse movements and get out of sync with their apps when the connection is slow or the server is loaded.
The flicker is caused by the delay between the background of the window being painted and the painting of the various graphics in the foreground. as X stands, the window is mapped and immediately cleared to the background color. an Expose event is then generated which must propagate to the client, who only THEN can start drawing into the window. It seems that no matter what, one is stuck with a small amount of time in which the solid background color of the window is displayed. The workaround is simple, first you must make sure you can draw the contents of the window quickly, if your graphics may be complicated, the best way to do this is with a backing pixmap of exactly the same size as your window. The trick is to use XSetWindowBackgroundPixmap to set the background to None. this means that even when the window is mapped, nothing will be written to the screen, so the first and only thing the user will see is whatever you draw into it. This does not improve the latency situation, but solves the whole flicker problem.