2012.12.5

1.关于RenderingWindow

不是只有FrameWindow可以拥有RenderingWindow，CEGUI中所有的Window对象都可以拥有，调用Window::setUsingAutoRenderingSurface(true)，就会为Window对象实例化一个RenderingWindow，该Window的内容首先会渲染到该RenderingWindow对应的纹理中cache起来。调用Window::setUsingAutoRenderingSurface(false)就会销毁绑定的RenderingWindow。用不用RenderingWindow，不影响最终的渲染结果，但是肯定影响渲染效率。

关于RenderingWindow有两个地方比较奇怪：

1、RenderingWindow的资源管理并不由Window类进行，而是在RenderingSurface类系中自己管理，并且这种管理只涉及销毁，与渲染无关，渲染还是在Window对象树中进行。由于资源管理在RenderingSurface类系中进行，所以每次Window对象的RenderingWindow对象创建、销毁和改变时，都要在RenderingSurface对象树中进行修改，还是比较麻烦的，而我现在也看不出，作者这样写的好处是什么，不过应该是有好处的，或者是我想的把RenderingWindow的资源管理放在Window类进行是行不通的。

2、被旋转的WIndow对象必须要有RenderingWindow，如果没有，在WIndow::onRotate()中会实例化一个。其实也可以绕过Window::setRotation函数，通过调用Window对象的GeometryBuffer对象的setRotation来进行旋转，这样不会实例化RenderingWindow对象，同时也可以旋转Window，但我用这种方法，结果会少几个像素，不是pivot的问题，那个我也设置了，是什么原因目前我不是很清楚。

2.字符串与数字之间转换的效率

转换一般而言有两套方法，一是用标准库的io类库，二是用底层C函数。我实验了一样，ostringstream比sprintf慢了10倍多，istringstream比itoa慢了20多倍，所以底层的转换功能还是用C函数吧。

在CEGUI的XML解析器中用了很多标准库的io类，可以全部换掉。

3.公共方法中不出现虚方法？

CEGUI很多类都是这么做的，一个public非虚接口里面调用protected实现具体功能的虚函数，这样的手法有个名字叫NVI(None Virtual Interface)。有时候，某个虚接口做的事不同派生类中不同，但它做事之前和之后要完成的事却是固定的，例如上锁和解锁，这种时候就是应该使用NVI的时候了，在public非虚方法前后上锁和解锁，在中间调用完成具体工作的虚方法。由于客户代码只能调public方法，这样就保证那些事前和事后必须完成的工作能够完成。

4.CEGUI的XML解析

解析由三个类完成，Attributes、Parser和Handler。

Attributes类可以看成是一个map，记录属性名和属性值。

Parser负责解析文件，它读取到xml文件中的一个节点后，会获得该节点的名字，并把所有属性对记录到Attributes对象中，然后用它们做参数调用Handler对象的elementStart方法，遇到节点结尾就调Handler对象的elementEnd方法，遇到节点开头和节点结尾直接的文字段时，调用Handler对象的text方法。CEGUI的CEGUIXMLParser是一个接口类，我下的版本里面提供了一个实现--CEGUIExpatParser，它实际是调用Expat库，实现Parser接口。

Handler对象获取节点名字以及里面的属性值后，就可以做相应的事了。CEGUIXMLHandler是一个接口类，针对不同的功能，由不同的派生类实现它，例如处理layout文件的GUILayout_xmlHandler类。如果以后定义了一种新的配置文件，它也是XML，那么就需要为它实现一个CEGUIXMLHandler的派生类。

有输入当然也有输出，CEGUI提供了了XMLSerializar类，它是一个实体类，用来帮助输出XML，还是很好用的，如果以后有XML文件的处理需求，可以直接用这些代码了。