今天打開Windows 8的時候發現來自了Windows Essentials 2012的更新，發現里面已經包含了一個Windows Live Writer。以前每次打開cppblog直接寫博客的時候都很苦逼，又懶得下載這些軟件，結果今天發現既然已經裝了，那就來試試看。用著的時候還挺舒服的。

插個圖片試試：

所有關于渲染的部分的代碼可以在http://gac.codeplex.com下載下來之后，在\Libraries\GacUI\Source\GraphicsElement目錄下面找到。

整個渲染系統的主要思想就是，圖元（IGuiGraphicsElement）和渲染器（IGuiGraphicsRenderer）分開，而且粒度根據性能的要求粗細都有。為什么要這么設計呢？在前言里面說過，不同的渲染設備，譬如GDI和DirectX，需要的渲染策略和cache資源的方法都不太一樣。因此為了讓各個渲染設備的渲染器可以充分自定義渲染的策略，于是做出了這樣的設計。

但是具體是怎么做的呢？在GacUI里面，首先可以用GetGuiGraphicsResourceManager來獲取一個全局的資源管理器（GuiGraphicsResourceManager）對象。這個對象的主要作用就是注冊各種創建圖元和渲染器的工廠對象。為了讓整個渲染系統運行起來，首先我們要把各種圖元工廠（IGuiGraphicsElementFactory）注冊進去。每一個圖元工廠有自己的一個全局的名字。這樣當你把一個圖元工廠注冊金資源管理器之后，從此就可以用圖元的名字從資源管理器里面取出注冊進去的圖元工廠對象了。

其次，因為在運行的時候，每一個圖元對象都會在內部保存一個專門給這個圖元對象用的渲染器對象，具體的渲染設備的渲染器可以在這個渲染器對象里面cache一些資源，就可以達到為某個圖元cache特殊的資源的目的了。因此為了給圖元對象創建合適的渲染器對象，我們還需要將圖元工廠的名字和一個渲染器工廠（IGuiGraphicsRendererFactory）關聯起來。當這一步完成之后，我們就可以通過下面的代碼來給一個圖元關聯上正確的渲染器對象：

IGuiGraphicsElement* element = xxxx;
IGuiGraphicsElementFactory* elementFactory = element->GetFactory();
IGuiGraphicsRendererFactory* rendererFactory = GetGuiGraphicsResourceManager()
        ->GetRendererFactory(elementFactory->GetElementTypeName());
IGuiGraphicsRenderer* renderer = rendererFactory->Create();
renderer->Initialize(element);

這樣我們就從一個IGuiGraphicsElement對象構造出了對應的IGuiGraphicsRenderer對象，并且將這個渲染器對象和這個圖元對象關聯了起來。這一步完成之后，渲染器對象就會開始根據需要cache被關聯的圖元對象所需要的資源。然后我們只需要把渲染器對象的指針告訴圖元對象，那么圖元對象就可以在自己被更新的時候，通過調用renderer->OnELementStateChanged()適當通知一下渲染器對象，而且也可以用renderer->GetMinSize()來說的顯示這個圖元所需要的最小的矩形尺寸了。為什么尺寸要通過渲染器來計算呢？主要是因為具體怎么渲染是渲染器來控制的，所以尺寸當然也是需要讓渲染其計算的，其中一個例子就是文字渲染了。

接下來就是如何規劃圖元的問題了。目前GacUI所有的圖元如下所示：

Gui3DBorderElement

Gui3DSplitterElement

GuiGradientBackgroundElement

GuiImageFrameElement

GuiPolygonElement

GuiRoundBorderElement

GuiSolidBackgroundElement

GuiSolidBorderElement

GuiSolidLabelElement

GuiColorizedTextElement

我們可以看到，大部分的圖元都是很簡單的。GuiSolidLabelElement就稍微復雜一點，具有了一些諸如自動換行啊省略號這樣的設置。而最復雜的就是GuiColorizedTextElement了，里面按行保存了文本之后，還按行給每一個字符分配了存放顏色的緩沖區，然后實現了字符串修改的時候緩沖區的分配釋放更新等操作。為什么不設計一個GuiCharElement，而是做成了這兩個東西呢？因為在普遍情況下，渲染器都支持對復雜的文字一次性渲染完成，如果我們把每一個字符都設計成一個圖元，讓排版引擎去渲染字符串的話，性能低下不說，效果可能還不如渲染器自己渲染出來的好。關于這里的一個典型的例子就是Windows所支持的可以連筆的OpenType技術了。另一個原因就是，在開發著色文本框的時候，如果所有的渲染過程不包含在一個圖元，而是分散在各個字符圖元的話，那更新文字和顏色的時候，無疑十分浪費內存，并且操作起來非常的麻煩，為了靈活性犧牲了太多的性能，得不償失。

說完了圖元和渲染器，最后一個要介紹的就是渲染目標對象（IGuiGraphicsRenderTarget）了。盡管渲染目標可以指向很多種地方，但是在一般情況下，渲染目標所指向的都是一個窗口的客戶區域（client area）。盡管在設計上這樣看起來僅僅是很自然，但是實際上這么一個對象卻是必須的，因為Direct2D的一個render target創建出來的畫刷等資源不能直接用在另一個render target上面，而且當render target掛掉的時候，那些資源要全部干掉，重新創建render target，并且重新創建資源。這一步作為一個bug登記在了GacUI里面，還沒實現，所以現在Direct2D渲染的時候，把窗口最小化再打開，有時候會變黑。

渲染目標對象的另一個功能就是計算clipping了。在形成父子關系的排版對象綁定的圖元在渲染的時候，子圖元是不能超出父排版對象的矩形范圍的。而且鑒于大量的對象可能處于不可見的位置，所以外圍的驅動渲染的代碼要在渲染對象完全被clip沒了的時候（譬如說在一個具有滾動條的容器里面，一個因為滾動條的關系看不見的按鈕），停止渲染看不見的那顆子樹，加速渲染過程。而且各個渲染設備也需要處理類似于一個文字只有上半部分能看見這樣的情形。所以排版對象就可以通過提供他自己的矩形范圍給渲染目標對象，從而讓渲染目標對象自己計算可見的矩形范圍，從而配合整個渲染流程的進行。鑒于有一部分的渲染器需要的資源是從渲染目標對象來的，因此IGuiGraphicsRenderer還有一個叫做SetRenderTarget的函數，用于在渲染對象發生變化的時候，譬如說因為窗口最小化從而造成Direct2D的render target的時效，需要重新創建的時候，通知每一個圖元綁定的渲染器說，整個渲染目標對象已經換掉了，一些資源可能要重新創建。

當然在這里需要提出的就是，在GacUI的GDI和Direct2D渲染器的實現里面，是有一些依靠引用計數全局cache的資源。譬如說在同一個渲染目標對象里面渲染的兩個同樣顏色的矩形，他在內部使用的具體的畫刷就不會真的重復創建兩次。盡管GDI和Direct2D的策略不同，GDI的畫刷是全局的，而Direct2D的話刷只對一個render target有效，GacUI還是提供了一個通用的資源cache算法模板，讓實現類似的功能更加方便。

有關渲染系統的內容就說到這里了，下一篇文章將會具體講排版對象的內容。

說起GacUI（www.gaclib.net，gac.codeplex.com），其實這個想法在我還在上大三的時候就已經有了。但是由于經驗不足，在當時并沒能夠把這個東西給做出來，直到去年（2011）的國慶節為止。想想到現在也做了快一年了，GacUI也可以用來寫一些不是特別殘暴的C++GUI程序了。前幾天有人問道，為什么在PC都快完蛋了并且大部分GUI都已經用C#來做的時候，我還要做這個東西呢？其實，這有兩個原因：第一個我喜歡折騰C++；第二個C++好像也沒什么特別好的GUI，因此也想嘗試一下，如果做成了就維護下去，做不成了好歹還可以提高自己的水平，總之是不會浪費時間的。所以我就在想，GacUI寫到現在也快一年了，并且我最近也看到cppblog上面有幾個人也想搞搞GUI，因此我想把GacUI的一些設計思想，和我得到這些思想的過程寫出來，順便也介紹一下GacUI的架構，讓一些有興趣的人（特別是裝配腦袋）也可以來折騰折騰。

GacUI的架構的最重要一點就是要跨平臺。當然這不一定意味著我將來一定會把GacUI移植到別的什么操作系統去，但至少Windows的Classic Desktop和Metro的兩套API就毫無相似之處，同時搞定他們，也算是跨平臺了。而且就算是基于同一種API，上面還有不同的渲染器的API，譬如說GDI，譬如說Direct2D，他們也是截然不同。GacUI的設計至少要可以屏蔽掉他們的區別。當然，這在技術上有一個很好的方法來保證，就是GacUIIncludes.h里面不包含Windows.h的任何內容——因此至少在頭文件里面，所有的東西都是跟Windows無關的。當然在非GUI的部分，我們還是需要Windows.h的，并且有些人喜歡對GacUI做點hack的操作，因此我還是在GacUI.h里面提供了幾個額外的依賴于Windows.h的函數來暴露一些內部細節。那這樣如何跨Classic Desktop和Metro呢？有一個簡單的方法，就是可以在編譯的時候給些宏開關，譬如說GACUI_WINDOWS_CLASSIC_DESKTOP（缺省）或者GACUI_WINDOWS_METRO之類的東西，來屏蔽掉不需要的部分。當然這部分在移植到Metro之前我不會加進去。

基于這個想法，如果大家閱讀了GacUI的代碼的話，會發現在文件\Libraries\GacUI\Source\NativeWindow\GuiNativeWindow.h里面定義了一個INativeController接口，而且目前只有Windows Classic Desktop一個實現。INativeController的內容很多，提供了跟具體的平臺有關的操作，譬如說讀寫圖片文件啦、創建消滅窗口啦、顯示器操作啦、還有各種其他的輸入輸出等等。實現一個從頭INativeController還是比較繁瑣的，因為GUI這種對操作系統重度依賴的東西，想剝離開來，就會發現他依賴了一大坨API。這也解釋了為什么INativeController的各個XXXService函數返回的對象的方法的總和有上百個。不過從Classic Desktop移植到Metro還是相對比較簡單的，因為大部分內容還是可以共享的。

其次就是渲染器了。渲染器跟平臺是交叉依賴的。譬如說OpenGL在linux上和Classic Desktop上都可以用，Direct2D在Classic Desktop上和Metro上都可以用，GDI只能在Classic Desktop上面用。因此這就是為什么我最終沒有把渲染器也寫在INativeController里面，而是把渲染器整個給屏蔽掉了，根本沒有在GacUIIncludes.h里面給出他的接口。但是考慮到GacUI是一個支持換膚的GUI庫，因此肯定需要讓皮膚來自己決定如何繪圖。后來我就想了一個辦法，把渲染器的結構整個拿掉，替換成各種各樣的圖元（IGuiGraphicsElement）。所謂的圖元就是類似于方形啊，圓形啊，填充啊，漸變啊，文字之類的東西。皮膚自己把圖元按照一定的排版關系（在下文中有描述）拼裝好，然后GacUI內部的一個小系統會利用Bridge和Abstract Factory兩個模式的結合體（參考\Libraries\GacUI\Source\GraphicsElement\GuiGraphicsElement.h）來為這些圖元分配好渲染器對象（IGuiGraphicsRenderer）。然后圖元和渲染器之間用了Listener模式在交換信息。這樣的好處是，當圖元受到改動的時候，這個圖元對象的專用渲染器對象可以選擇cache一些信息，然后在窗口渲染的時候，只需要訪問所有的渲染器對象（在排版對象GuiGraphicsComposition的組合項形成了一棵樹），讓他們渲染自己就可以了。

圖元包含了所有需要渲染的數據，但是唯獨沒有把尺寸寫進去，因為尺寸這種東西不應該讓渲染器來負責，而應該讓排版對象來負責。排版對象自己是一棵樹，然后節點根節點之間有一些關系，這樣就可以實現堆棧排版、表格排版、對齊（到某一些邊上的）排版等等具體的排版算法。一個排版對象可以放置一個圖元對象并讓這個圖元充滿他，所以顯而易見，有一些排版對象僅僅是用來計算尺寸的中間結果，上面不一定有圖元對象的。當渲染開始的時候，排版對象首先跟圖元對象獲取數據，然后遞歸計算好整棵排版樹的尺寸，最后把尺寸交給附著在上面的圖元對象的專用渲染器對象來渲染。

大家可能會想，如果渲染一次都需要調用成千上萬個虛函數的話，會不會性能低下啊？當然編譯成Release運行會發現GacUI的性能還是相當高的。原因有兩個。第一個是我對排版對象做了一些優化。舉個例子，一個對象的尺寸至少要大于所有子對象的尺寸，這個事情計算起來是相當快的，不需要做cache。但是一個表格排版里面的所有小格子會互相擠來擠去，這個東西計算起來相當復雜（復雜度大越是平方，而且系數也不笑），所以結果要做cache。但是什么時候需要重新計算呢？度量方法很簡單，就是每一個格子的最小尺寸發生了變化的時候。而且事實上大部分皮膚都是用表格來排版的，所以等于說大部分結果都有cache。所以排版部分的尺寸在每一次渲染的時候只需要做一些小計算就可以了。復雜的排版每一個排版對象相互之間都是有關系的，一個排版對象發生了變化，有可能導致另一個排版對象的尺寸需要修改，所以最簡單的方法就是，不保存尺寸，每一次都直接重新算一次就可以了。在這個基礎上，表格排版做一下cache，整個計算過程就會變得飛快。所以盡管每一次拖動窗口，或者鼠標滑過一次窗口，都要進行相當多的計算，但是因為有一個智能的cache，使得不僅運算速度變快，而且在添加新的排版對象類型的時候也根本不需要考慮自己會不會被cache的問題，開發起來也相當愉悅。

所以上面的三大模塊（操作系統API隔離、渲染器、排版對象）已經足以讓我在系統里面開一個窗口然后在上面放各種各樣的東西了，譬如說組合成一個非常接近Windows7的按鈕外觀的一個矢量圖。那控件要怎么辦呢？其實一個控件，就是通過接收用戶的輸入，對一個排版對象上承載的一大堆圖元進行更改。用戶的輸入和控件（GuiControl）本身的狀態進行互動，然后控件把狀態的變更提交給控件的皮膚（GuiControl::IStyleController），最后皮膚通過修改圖元來把狀態變更最終展現給用戶。一個典型的例子就是，在使用Windows7皮膚的時候，鼠標移動到按鈕上面去，他會觸發一個動畫慢慢變成藍色。

GacUI的大體架構就是這個樣子了。在接下來的幾篇文章里面，我會詳細介紹每一個子系統的內部結構，順帶做以下代碼導讀，大家敬請期待。

    GacUI的所有列表控件都支持虛擬模式。虛擬模式是一種不需要為每一個列表項分配內存的一種顯示方法。在開始的時候，需要高速列表一共有多少個列表項。之后，列表控件在渲染的時候，會跟數據源要求獲取某一個下標所包含的數據，并且在這個數據一直處于屏幕上的時候，只會跟數據源獲取一次。完整的代碼可以在http://www.gaclib.net/Demos/Controls.ListBox.VirtualMode/Demo.html看到。先上圖：



    先看創建界面的代碼。一般來說，所有可以隨著窗口的變化自動排版的控件組織方法，都是使用一個或多個GuiTableComposition來實現的。

class VirtualModeWindow : public GuiWindow
{
private:
    GuiVirtualTextList*                    listBox;
    GuiButton*                            buttonIncrease;
    GuiButton*                            buttonDecrease;
    DataSource*                            dataSource;
    
    void buttonIncrease_Clicked(GuiGraphicsComposition* sender, GuiEventArgs& arguments)
    {
        dataSource->SetCount(dataSource->Count()+100000);
    }

    void buttonDecrease_Clicked(GuiGraphicsComposition* sender, GuiEventArgs& arguments)
    {
        dataSource->SetCount(dataSource->Count()-100000);
    }
public:
    VirtualModeWindow()
        :GuiWindow(GetCurrentTheme()->CreateWindowStyle())
    {
        this->SetText(L"Controls.ListBox.VirtualMode");

        GuiTableComposition* table=new GuiTableComposition;
        table->SetRowsAndColumns(3, 2);
        table->SetCellPadding(3);
        table->SetAlignmentToParent(Margin(0, 0, 0, 0));

        table->SetRowOption(0, GuiCellOption::MinSizeOption());
        table->SetRowOption(1, GuiCellOption::MinSizeOption());
        table->SetRowOption(2, GuiCellOption::PercentageOption(1.0));

        table->SetColumnOption(0, GuiCellOption::PercentageOption(1.0));
        table->SetColumnOption(1, GuiCellOption::MinSizeOption());

        this->GetContainerComposition()->AddChild(table);
        
        {
            GuiCellComposition* cell=new GuiCellComposition;
            table->AddChild(cell);
            cell->SetSite(0, 0, 3, 1);

            dataSource=new DataSource;
            listBox=new GuiVirtualTextList(GetCurrentTheme()->CreateTextListStyle(), GetCurrentTheme()->CreateTextListItemStyle(), dataSource);
            listBox->GetBoundsComposition()->SetAlignmentToParent(Margin(0, 0, 0, 0));
            listBox->SetHorizontalAlwaysVisible(false);
            cell->AddChild(listBox->GetBoundsComposition());
        }
        {
            GuiCellComposition* cell=new GuiCellComposition;
            table->AddChild(cell);
            cell->SetSite(0, 1, 1, 1);

            buttonIncrease=g::NewButton();
            buttonIncrease->SetText(L"Increase 100000 Items");
            buttonIncrease->GetBoundsComposition()->SetAlignmentToParent(Margin(0, 0, 0, 0));
            buttonIncrease->Clicked.AttachMethod(this, &VirtualModeWindow::buttonIncrease_Clicked);
            cell->AddChild(buttonIncrease->GetBoundsComposition());
        }
        {
            GuiCellComposition* cell=new GuiCellComposition;
            table->AddChild(cell);
            cell->SetSite(1, 1, 1, 1);

            buttonDecrease=g::NewButton();
            buttonDecrease->SetText(L"Decrease 100000 Items");
            buttonDecrease->GetBoundsComposition()->SetAlignmentToParent(Margin(0, 0, 0, 0));
            buttonDecrease->Clicked.AttachMethod(this, &VirtualModeWindow::buttonDecrease_Clicked);
            cell->AddChild(buttonDecrease->GetBoundsComposition());
        }

        // set the preferred minimum client size
        this->GetBoundsComposition()->SetPreferredMinSize(Size(480, 480));
        // call this to calculate the size immediately if any indirect content in the table changes
        // so that the window can calcaulte its correct size before calling the MoveToScreenCenter()
        this->ForceCalculateSizeImmediately();
        // move to the screen center
        this->MoveToScreenCenter();
    }
};

    GuiVirtualTextList就是只有虛擬模式的GuiTextList。事實上GuiVirtualTextList是GuiTextList的基類，而GuiTextList.GetItems()返回的對象也是一個數據源。因此非虛擬模式其實也是通過虛擬模式來實現的。在數據比較少的時候，非虛擬模式操作起來十分的簡單，而在數據比較多的時候，虛擬模式可以帶來很好的性能。上面的代碼創建了一個DataSource類來做數據源，并且有一個SetCount的函數用來更改列表里面的數量的總量，然后每一個列表項的內容都是Item xxx。這是怎么做到的呢？我們來看數據源的代碼：

class DataSource : public list::ItemProviderBase, private list::TextItemStyleProvider::ITextItemView
{
protected:
    int                count;
public:
    DataSource()
        :count(100000)
    {
    }

    void SetCount(int newCount)
    {
        if(0<=newCount)
        {
            int oldCount=count;
            count=newCount;
                
            // this->InvokeOnItemModified(affected-items-start, affected-items-count, new-items-count);
            // this function notifies the list control to update it's content and scroll bars
            if(oldCount<newCount)
            {
                // insert
                this->InvokeOnItemModified(oldCount, 0, newCount-oldCount);
            }
            else if(oldCount>newCount)
            {
                // delete
                this->InvokeOnItemModified(newCount, oldCount-newCount, 0);
            }
        }
    }

    // GuiListControl::IItemProvider

    int Count()
    {
        return count;
    }

    IDescriptable* RequestView(const WString& identifier)
    {
        if(identifier==list::TextItemStyleProvider::ITextItemView::Identifier)
        {
            return this;
        }
        else if(identifier==GuiListControl::IItemPrimaryTextView::Identifier)
        {
            return this;
        }
        else
        {
            return 0;
        }
    }

    void ReleaseView(IDescriptable* view)
    {
    }

    // list::TextItemStyleProvider::ITextItemView

    WString GetText(int itemIndex)
    {
        return L"Item "+itow(itemIndex+1);
    }

    bool GetChecked(int itemIndex)
    {
        // DataSource don't support check state
        return false;
    }

    void SetCheckedSilently(int itemIndex, bool value)
    {
        // DataSource don't support check state
    }

    // GuiListControl::IItemPrimaryTextView

    WString GetPrimaryTextViewText(int itemIndex)
    {
        return GetText(itemIndex+1);
    }

    bool ContainsPrimaryText(int itemIndex)
    {
        return true;
    }
};

    對于GuiVirtualTextList來說，只需要實現vl::presentation::controls::list::TextItemStyleProvider::ITextItemView就可以了。GacUIIncludes.h里面已經有了using namespace vl::presentation::controls，所以在這里只需要從list::開始寫。list::TextItemStyleProvider::ITextItemView還要求實現GuiListControl::IItemPrimaryTextView。在目前的GacUI里面，IItemPrimaryTextView是專門為下拉框準備的。因為下拉框允許接受任何一種列表對象當做下拉內容，所以GacUI的列表數據源默認都要求實現IItemPrimaryTextView。

    實現數據源的時候，其實并不要求數據源類繼承自ITextItemView和IItemPrimaryTextView。因為GacUI都是通過RequestView來獲取一個View的接口指針的，代碼如上。實現這兩個View也很簡單，在這里就不贅述了。

    GuiTextList就介紹到這里了，接下來的幾個Demo都將是關于ListView的。下一個Demo是ListView山寨Windows 7的資源管理器界面，可以在http://www.gaclib.net/Demos/Controls.ListView.ViewSwitching/Demo.html看到。具體內容將在下一篇博客中闡述。