Duilib 改造之路 <2> 渲染效果 1 不打马赛克的世界

<不附带任何源码,求源码者离场,请自行修改>

大约耗时:3-4小时

由于开发时间等问题,duilib的渲染方式是使用GDI的方式的,这意味着渲染效果会存在一定缺陷,当我们拉伸图片的时候很容易就会出现锯齿,一些图片的显示质量差,文字出现凹槽锯齿,无论你怎么修改xml,差一两个像素就会有一堆马赛克,怎么办?使用GDI+替代GDI

去瞄一下duilib的文档,duilib的所有绘制都会通过CRenderClip和CRenderEngine这个两个类来完成,然后我们分析一下类结构,可以发现所有的图像绘制都是通过DrawImage函数实现的,但问题的关键不在于绘制而是图片的存储

这是图片存储的结构体,里面描述了图片的一些属性,因为我们将会使用GDI+代替原来的GDI,所以我们修改一下这个结构体

好吧,先不要吐槽,这里也不是玩大家来找茬,我们使用GDI+的Bitmap代替HBITMAP,然后直接按一下F5,就会报一大堆错误,

这些错误可以帮助我们快速找到需要修改的地方,还是那句:没有必要完全掌握所有代码,因为只是"分工合作"

这些错误大概是类型不匹配和无法找到Bitmap*类型之流.后者只要添加GDI+支持就可以了,前者只需要一个转换函数就可了,但是具体的修改方案自行制定吧,不过有以下两个建议,

统一出入口,试想一下如果duilib原作者没有通过DrawImage函数来实现绘制,而是每个控件都有自己的绘制函数或者绘制流程,那么现在会发生什么事?

减少转换次数,应该在加载的时候进行转换,而不是绘制时转换

和duilib源码相比,我的duilib库引入了stl来代替原来的容器类,这样很大程度上使duilib的源码更加清晰,同时避免了duilib在实际工作中的不稳定性(duilib的很多BUG都是来源于自身的容器类,建议就是使用stl替换,但是这项工程非常庞大,所以现在还是逐步更替比较合适)

完成一大堆转换(复制黏贴)后,回到DrawImage函数,接下来就是GDI绘制转GDI+绘制的时间了,你需要的是一大堆纸和笔做四则运算(找个小学生来做可能快一点......),至于GDI+的绘制方式网上一大堆,我就不复制黏贴了.

下面就是文字的绘制,上面我们还可以修改一下结构体,但是这里我们只能直接面对DrawText函数了,因为GDI的文字绘制方式和GDI+完全不同,而且源码中没有对绘制文字的参数集中处理,部分控件对文字进行了处理,所以我们不可能像上面的方法那样去修改文字绘制,只能直接对DrawText函数(最后输出点)进行修改这里存在HFONT转Font(自行百度)

最后就是字串风格了,在GDI中是通过一个UINT来控制,但是到GDI+中却分门别类地进行,怎么统一?

下面提供一种参考方法

    

在GDI我们会通过不段对uStyle进行"|"(位或运算) 来添加风格,当要分解的时候我们可以像上面那样通过&(位与运算)来分解,然后转换成GDI+的字串风格,这组位运算可以用在很多地方,例如管理软件权限分配,游戏中的任务状态等.

最后就是一个小细节,关于字体绘制方式,TextRenderingHintClearTypeGridFit和TextRenderingHintAntiAlias(这两种比较合适),TextRenderingHintClearTypeGridFit会使字体更加"清晰"(连横竖的凹槽都看见了),而TextRenderingHintAntiAlias会使字体更加"模糊"(笔画长度变短,厚度均匀),基本上用哪一种都会有问题,所以建议大号字用TextRenderingHintAntiAlias,这样就不会有凹槽出现,小号字用TextRenderingHintClearTypeGridFit,这样字就会清晰没有锯齿

if(m_tfi->iSize <= 12)
{
graphics.SetTextRenderingHint( TextRenderingHintClearTypeGridFit );
}
else
{
graphics.SetTextRenderingHint( TextRenderingHintAntiAlias );
}