從某種意義上來說，做圖形也好，做GUI也好，做編譯器也好，大概都是一種情結。其實只要稍微想一想就知道，能把它們三者有機統一起來的，就只有游戲。我很久以前的確是為了想開發游戲才對編程產生興趣的，而學習游戲開發占據了我前六年的時間。雖然現在不做了，不過偶爾總是會覺得手癢。但是做游戲沒美工做不好怎么辦呢？就只好寫游戲代碼了。但是沒有資源寫出來的游戲又不好玩，于是就只好寫庫。那寫什么庫呢，自然就只有渲染器、界面引擎和腳本引擎了。我的博客的大部分文章也是圍繞著這三件事情建立起來，而且在中間不斷切換的。

    撒，所以今天就輪到GUI了。我一直很想做出一個自繪的GUI出來，無奈一直設計不出一個好的架構。后來嘗試用原生API，但是卻又很不喜歡MFC的設計，就嘗試自己照著.NET Framework和Delphi那套VCL的樣子封裝了一個控件庫出來。無奈原生API細節無敵多，后來沒做把所有的功能都全部做完。因此后來一段時間凡是需要界面我都直接用C#做。然后CEGUI出了，WPF和Silverlight也出了，我發現如今要做一個漂亮的GUI非自繪已經做不到了，所以我又做了一次嘗試。

    去年在美帝的時候曾經試圖再設計一次，得到了一些結果。后來我發現其實根本沒辦法為GDI、DirectX、OpenGL和其它繪圖設備抽象一個公用的接口，否則就會遭遇大量性能問題。因為在很多細節上，譬如說渲染文字，為了達到較高的性能，OpenGL和DirectX需要使用幾乎相反的策略來做。因此這次我又換了一個方法，而且在Vczh Library++ 3.0的Candidate目錄下已經checkin了一個試驗品。

    我把一個自繪的GUI分成了下面若干個層次。
    1、NativeWindow。NativeWindow表示的是一個頂層窗口的實現。譬如說我們想用Windows的窗口作為自繪窗口的頂層窗口（游戲里面的很多頂層窗口是繪制在游戲窗口里面的，所以頂層窗口并不一定是Windows的窗口）。
    2、控件庫。控件庫包含了這個自繪GUI庫的所有預定義控件。控件本身包含對用戶輸入的相應邏輯，但是每一個控件的繪制以及鼠標點中測試不在此范圍內。
    3、控件皮膚接口。每一個最終控件都會擁有一個控件皮膚接口。每當控件的狀態發生了變化，控件會調用皮膚接口更新控件的當前狀態。每當控件需要知道某一個點是否位于一個控件里面的時候，他也會去調用該控件的皮膚獲得結果。因此控件皮膚接口包含了一切關于繪制（因此理所當然也就包含了點中測試）的邏輯。

    為了達到最高的性能，一套皮膚的實現只能綁定在某種繪圖設備上，也就是說缺省狀態下一套為GDI設備設計出來的皮膚是不能直接使用在DirectX設備上面的。當然我這個框架的設計也是足夠開放的，如果你非得用同一套代碼來實現不同繪圖設備上的皮膚，那么你是可以自己動手豐衣足食，做到給GDI和DirectX設計一個公共接口并插入我的GUI框架的（只不過這種做法一般情況下都會慘死）。

    那么如何添加繪圖設備呢？目前NativeWindow有一個基于Windows窗口的實現，并且NativeWindow的接口要求該實現在創建、銷毀、接收到很多窗口事件的時候都調用某一個回調對象。我們可以通過注冊一個全局回調對象或者具體窗口的回調對象來獲得NativeWindow狀態的變更。基于Windows窗口的NativeWindow實現還提供了一個額外函數，可以讓你獲得一個NativeWindow的HWND（但這個函數并不被控件庫依賴）。現在我還實現了一個基于HWND+HDC的繪圖設備，主要方法就是先注冊全局回調對象，每當知道一個NativeWindow被創建了，我就會注冊一個NativeWindow的回調對象，用來維護一個窗口里面的一塊32位DIBSections位圖緩沖區。窗口的大小如果變化了，我也會在適當的時候重新創建一塊合適的緩沖區。不過為了避免每一次大小變化都會創建新的緩沖區，我創建的緩沖區的大小總會比窗口大一點。然后這個GDI繪圖設備就暴露了一個函數，可以獲得一個NativeWindow的HDC和WinGDIElementEnvironment。

    WinGDIElementEnvironment是基于HWND+HDC的這一套實現上專有的、為了GDI皮膚設計出來的一個公共的資源庫（譬如用來保存各種面向業務邏輯的pen啊brush什么的，比如說disable的時候什么顏色，選中的時候什么顏色等等）。如果你想設計一個基于HWND+DirectX的皮膚，那么類似WinGDIElementEnvironment的這套東西要重新做一次——因為為了達到相同的性能。具體細節相差太大。當然HWND+HDC上面可以有多套皮膚，WinGDIElementEnvironment是公用的。WinGDIElementEnvironment要求繪制是通過一個具體的WinGDIElement對象達到的，而一套皮膚可以有自己的一套WinGDIElement的實現。WinGDIElement被設計成面向業務的、一套皮膚的基本元素組成部分，譬如說按鈕邊框啦、焦點長方形啦、文字啦，而不是帶有pen和brush的長方形啊，文字啊，各種亂七八糟的最低等級的繪圖元素。舉一個例子，按鈕邊框跟菜單邊框很像，都可以用Rectangle來組成。但是Element里面就直接是按鈕邊框和菜單邊框，而不是一個可以讓你自由修改顏色的Rectangle。因為不同的控件要共享配色方案，而配色方案是由業務邏輯+空間狀態的集合實現的，因此WinGDIElement還是一個比較高層次的概念。當一個WinGDIElement被渲染的時候，他會給你一個HDC，然后你根據被設置的狀態來調用GDI函數繪制到HDC指向的32位DIBSections位圖緩沖區上面。

    那么，當我們使用HWND+HDC的實現，創建了一個布滿了控件的窗口，那實際上是發生了什么事情呢？首先控件自己會組成一棵樹。其次，控件的皮膚也會組成一棵樹。現在就有控件樹跟皮膚樹兩顆樹了。控件樹負責所有用戶輸入變更狀態的邏輯部分，而皮膚樹負責繪圖和點中測試。而一個HWND+HDC實現的皮膚樹，會在皮膚組合成樹的時候，在底下又組合出了一顆WinGDIElement樹。因此大局上就是：
    控件樹（負責相應輸入變更狀態）--> 皮膚樹（負責儲存控件狀態的可視部分并決定什么時候需要刷新）-->WinGDIElement樹（負責繪圖整個窗口）

    這個時候，如果我們僅僅需要簡單的重新繪制窗口的話，那么控件樹跟皮膚樹都不需要被訪問到，底層僅需要讓WinGDIElement樹重新繪制一遍即可。而WinGDIElement的粒度實際上也不小，因此不會每一個圖元都有一個WinGDIElement從而使得創建出了一大堆對象的。

    最后一個設計就是在什么時候才重繪窗口的問題。假設說我們現在收到了一個WM_KEYDOWN消息，最終傳播到了控件樹里面去，然后修改了10個控件上面的文字。每當你修改文字的時候實際上都需要重繪，那如何將無數次不可控的重繪合并成一次呢？SendMessage(WM_PAINT)是立刻執行的，所以Windows自帶的合并WM_PAINT的方法在這個時候是無效的。我所采取的解決方法就是：反正控件樹的所有消息來源都是從NativeWindow里面來的，那實際上控件樹發出一個重繪請求的時候，我就會把NativeWindow的HWND實現里面的一個bool變量設成true，然后當NativeWindow每一個傳播到控件樹的消息結束傳播之后，才讀一次那個變量，如果是true，那么就調用WinGDIElement進行重繪并把變量設計成false。壞處是每一個傳播到控件樹的消息在處理完之后都必須檢查是否需要重繪，好處是這個東西被封裝在了NativeWindow的HWND實現里面里面，無論是控件樹、皮膚樹還是WinGDIElement樹也好，都在也不需要關心繪圖時機的事情了。

    因為GUI被分割成了很多層，而且每一層的都關心業務邏輯的不同部分，所以他們都是可以被替換的。譬如說我們可以做成：
    HWND+HDC實現：最普通的方法
    HWND+DirectX：WPF和Silverlight地方法
    單一HWND+多個虛擬窗口+DirectX：可以在游戲里面用

    無論下面的繪圖設備和窗口實現如何發生變化，GUI控件的邏輯部分都跟這些實現嚴格分離，因此不會受到影響。而且大部分情況下，我們是不需要擁有一個跨繪圖設備的皮膚庫的，譬如說游戲和應用程序，外表總不能做成一樣的。對于那些需要同時在DirectX和OpenGL上面運行的程序（譬如說3dsmax），它已經有DirectX和OpenGL的公共接口了，因此這些軟件可以利用它們的公共接口來實現GUI的繪圖設備部分，從而在上面構造起來的皮膚自然是可以跨DirectX和OpenGL的。

    這比起一年前作的GUI實現又進了一大步。上一次的GUI嘗試為不同的繪圖設備抽象一套公共接口，后來慘死。不知道這次實際上做出來的效果如何，拭目以待吧。