今天打开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看到。具体内容将在下一篇博客中阐述。