註：在下對X Window的理解僅限於表面，文章中會有不少技術、歷史方面的錯誤，若有大俠指出，不勝感激！
古老的X Window和現代的桌面技術
X Window在1984年由MIT研發，它的設計哲學之壹是：提供機制，而非策略。舉個最簡單的例子吧：X Window提供了生成窗口（Window）的方法，但它沒規定窗口要怎麽呈現（map）或擺放（place），這個策略是由外部程序——窗口管理器（Window Manager）所決定的。另外壹個X Window的主要特點便是：Server/Client網絡模型。不論是本地、遠程的應用程序，都統壹通過Server/Client模型來運作，比如：讓遠程的應用程序跑在本地上。
X Window在推出之後快速演化，在1987年時候，其核心協議已經是第11版本了，簡稱：x11。這個版本已經將“提供機制，而非策略”這個哲學貫徹地非常徹底，以致於核心協議基本穩定，不需要特別大的改動。於是乎，妳看到了，現在是2010年，整整23年了，X Window依然是X11。
妳可能會詫異，23年了，X Window的核心都沒有特別大的變化，它能適應現代桌面的快速發展嗎？這就要再次提到X Window的設計優勢了，X Window在核心層之外提供壹個擴展層，開發者可以開發相應擴展，來實現自己的擴展協議，比方說：
標準的Window都是矩形的，我如何用它來畫壹個圓形的窗口？X Window協議並未提供，但是通過“shape”這個擴展，X Window可以實現不規則的窗體。
所以啊，這23年，X Window除了繼續完善核心協議、驅動以外，很大程度上，都是擴展使它保持“與時俱進”，比如說：
要多頭顯示支持，這個是由“Xinerama”擴展實現的；
要有多媒體視頻回放的支持，這個是由“X Video”擴展實現的;
OpenGL的3D支持，則是通過“GL”擴展來實現的；
Compiz那樣的合成桌面特效是怎麽弄的？沒錯，還需要壹個新的擴展，它便是：“Composite”；
甚至Keyboard的支持，都是通過“X Keyboard Extension”（也就是“XKB”）的！
X Window的核心，基本上就是在處理Server/Client、驅動之類的，而外部的那些支持，基本上全是通過“擴展”進行的。這沒什麽不好，X Window的結構設計精良，盡管是擴展，但它們沒有任何效能上的問題。通過擴展方便地實現了壹些對新技術、新事物的支持，而且方便維護，這再好不過了。
所以妳看到了盡管23年過去了，基於X Window的GNOME、KDE，還能保持與同期Windows、Mac OS X競爭甚至某些方面更好，妳就不得不佩服這些前輩在最初設計時定下的設計哲學是多麽正確了。
雖然擴展的眾多沒有給X Window造成什麽問題，也跟X Window的設計哲學相符，但是其Server/Client的網絡構架，卻壹直倍受質疑，這便是：
X Window的效率問題
經常聽到有人說，X Window的Server/Client結構嚴重影響效率，導致Linux桌面的效應速度壹直不如Windows、Mac OS X。事實是不是這樣呢？讓我們還是透過原理來說話吧。
這張，便是當前X Window系統的架構圖，稍微解釋壹下：
X Client：圖形應用程序，如Firefox、Pidgin等；
X Server：妳看不見的控制中心；
Compositor：合成桌面系統，如Compiz；
Kernel/KMS/evdev：這便是Linux Kernel，後面會提到KMS技術了，其中還有壹項evdev，是管理輸入設備的。
X Architecture
通過這些箭頭，妳已經可以明白壹些X Window的工作機制了，不過還從壹個應用場景來解釋壹下，想像壹下，當妳點擊了Firefox（X Client）的“刷新”按鈕，將會發生以下事情：
妳用鼠標點擊了Firefox的“刷新”按鈕，這時內核收到了鼠標發來的事件，並將其通過evdev輸入驅動發送至了X Server。這時內核實際上做了很多事情，包括將不同品牌的鼠標發出的不同信號轉換成了標準的“evdev”輸入信息。
這時X Server可以判斷哪個Window該收到這個消息，並將某座標按下按鈕的消息發往X Client——Firefox。但事實上X Server並不知道它得到的窗口信息是不是正確！為什麽呢？因為當前的Linux桌面早已經不是10年前的那樣了，現在是“Composite”即合成桌面的時代，合成桌面的壹個特點便是：Compositor（如Compiz）管理窗口的壹切，X Server只能知道屏幕的某個點收到了鼠標消息，卻不知道這個點下面到底有沒有窗口——誰知道Compiz是不是正在搞壹個漂亮的、緩慢的動畫，把窗口收縮起來了呢？
假設應用場景沒這麽復雜，Firefox順利地收到了消息，這時Firefox要決定該如何做：按鈕要有按下的效果。於是Firefox再發送請求給X Server，說：“麻煩畫壹下按鈕按下的效果。”
當X Server收到消息後，它就準備開始做具體的繪圖工作了：首先它告訴顯卡驅動，要畫怎麽樣壹個效果，然後它也計算了被改變的那塊區域，同時告訴Compiz那塊區域需要重新合成壹下。
Compiz收到消息後，它將從緩沖裏取得顯卡渲染出的圖形並重新合成至整個屏幕——當然，Compiz的“合成”動作，也屬於“渲染（render）”，也是需要請求X Server，我要畫這塊，然後X Server回復：妳可以畫了。
整個過程可能已經明了了，請求和渲染的動作，從X Client->X Server，再從X Server->Compositor，而且是雙向的，確實是比較耗時的，但是，事實還不是如此。介於X Window已有的機制，盡管Compiz已經掌管了全部最終桌面呈現的效果，但X Server在收到Compiz的“渲染”請求時，還會做壹些“本職工作”，如：窗口的重疊判斷、被覆蓋窗口的剪載計算等等（不然它怎麽知道鼠標按下的坐標下，是Firefox的窗口呢）——這些都是無意義的重復工作，而且Compiz不會理會這些，Compiz依然會在自己的全屏幕“畫布”上，畫著自己的動畫效果……
從這個過程，基本可以得出結論：
X Client <-> X Server <-> Compositor，這三者請求渲染的過程，不是很高效；
X Server，Compositor，這兩者做了很多不必要的重復工作和正文切換。
當然，這裏我沒有直接說明這種模式有沒有給X Window造成效率問題，因為我們還少壹個對照組。再看對照組之前，再來看看X Server的另壹個趨勢：
從“什麽都做”到“做得越來越少”的X Window
X Window剛出現那會，主要提供壹個在操作系統內核上的抽象層，來實現壹個圖形環境。所謂圖形環境，最主要的便是：圖形＋文字。當時的X Window便提供“繪圖”和“渲染文字”的機制。圖形桌面上的圖案和文字，都通過X Window合成並繪制出來。
壹個典型的例子，如果妳要用X來畫點，就要在妳的程序中通過“XDrawPoint”來進行，X Server收到消息後，便會畫出相應的點。
現在，稍微接觸過圖形開發的人都知道了，在X Window下，壹般都通過GTK+和Qt來進行了。更深壹層的是，通過Cairo（Qt不是）來繪制圖形。Cairo是什麽？它是壹個繪圖＋渲染引擎，著名的瀏覽器Firefox，便是使用Cairo來渲染網頁和文字的。
Cairo是壹個全能的、跨平臺的矢量繪圖庫，它不是簡單的包裝壹下各個平臺的繪圖庫而已，盡管它最初是基於X Window開發出來的繪圖庫。現在Cairo支持各種不同的後端，來向其輸出圖形，比如X、Windows的GDI、Mac OS X的Quartz，還有各種文件格式：PNG、PDF，當然還有SVG。可以說，Cairo是壹個很徹底的、全能的繪圖庫，現在無論繪制什麽圖形，都不會考慮到用XLib了。
在Cairo之上，還有文字排版庫：Pango，同樣很明顯的，處理文字排版，都不會用XFont之類的東西了，而是直接用Pango畫。當然Pango也是跨平臺的。
盡管在Linux平臺下，Cairo、Pango的發揮依然是基於X Window的，但X Window充其量僅僅是壹個“backend”而已，並不是少它不行。同理，跨平臺的GTK+、Qt也只是視X為其中所支持的後端之壹，假如哪天X真的不在了，更換壹個新後端，當前的GNOME、KDE也能完整的跑起來。
再提另外壹個比較典型的關於“X曾經做的，但現已不做”的例子，便是“模式設置（mode-setting）”，說通俗點，就是“分辨率的設置”，但後面會說明不僅僅如此。
大家都知道，Linux只是壹個內核，它只有控制臺，通過Shell來進行交互，而控制臺默認是80x24（單位：字符）的，要進入分辨率1024x768或更高的圖形模式，就需要X進行壹次“模式設置”，設置正確的分辨率等等。
盡管後來Linux也支持了各種用戶層（user-space）的模式設置，讓終端也支持標準的分辨率，但是X的模式設置與此是不相幹的，所以壹兩年前，在Linux的啟動過程中，從終端進入圖形界面時，屏幕會“閃”壹下，這時便在進行“模式設置”——這裏就壹定要用“模式設置”這個術語了，因為即使終端是1024的，進入X圖形也是1024的，模式的變更還是要進行。