博客也荒废了

不想干事情的状态再持续下去的话，整个人就会完全废掉了。

其实需要干的事情很多很多啊。结果都扔在那里。然后自己一个人呆在一边发呆。

需要动力啊。

最近在做图形库的接口抽象。之前做的widget引擎和图形库的耦合过于紧密了，现在想要加上DX的支持的话就相当于整个项目重写一遍。没有办法，只好想办法把图形库的通用接口抽离出来。之后用DX实现一下那套接口。说起来貌似挺容易。但是从哪个层次抽离接口呢。由于我们原来使用的是Cairo图形库，最初的想法是把Cairo的每一个API都当作是接口的一个函数。这样做改动不大，原来的代码可能几乎不怎么动就能把接口抽离。问题在于抽离了接口之后，怎么去实现…Cairo是一套平面矢量库，DX的API跟它差的十万八千里。要用非常别扭的方法才能实现那些接口。那样做的结果只有性能下降。本来用DX是要提高性能的，这样做实在得不偿失。

于是只好在较高的层面来做抽象。分析widget里面每个DOMObject衍生类使用到Cairo的函数，发现主要使用到的其实只有render和translate两个函数（其实translate本来也是属于render的一部分，后来因为通用性强才抽出来做独立的函数的），除此之外还有一些使用到的，比如getCurentRect，或者img::setSRC,这些函数其实本可以不使用Cairo，比如setSRC完全可以只是设置一个字符串路径。 到render的时候才去读取文件。这样一方面能提高些许效率（假如有人反复setSRC却不显示那个图片，其实本不需要读取那个文件），另一方面也能减少DOMObject和图形库的耦合。至于getCurrentRect之类，应该在每次render的时候将位置，大小还有mask(用于hittest)的信息存储在某处，想要获取的时候直接去用就好了。这样做就几乎把所有跟图形库的耦合全都缩小到render函数里面了。之后只需写一个公共接口，然后用工厂方法对不同的DOMObject子类生成不同的render实现传指针进去就好了。这样在有DX支持的系统上，可以使用DX,而在没有DX支持的板子上，程序可以动态适应，换用Cairo版的render实现。比较灵活。

这两天总算拖着拖着做了这么一点，接口基本上抽离出来了，但是抽出来之后发生了一些bug, 主要是TextArea和Colorize部分出了问题。争取尽快把bug解决掉好提交代码吧。。还有太多太多事情等着我做呢！！