GTK+2.6 + DirectFB的几个问题

GTK+2.6 + DirectFB的几个问题

 

经过几番周折，终于确定采用GTK+2.6 + DirectFB方案。之所以不选择GTK+2.8 + TinyX主要是出于硬件成本上的考虑，TinyX(包括Xlib等库文件)要占4M Flash空间，加上窗口管理器还要耗好几M的RAM，同时进程间通信过于频繁，性能上的开销也不容小觑。

 

为什么不选择GTK+2.8 + DirectFB呢？原因是2.8及以后采用cairo作为画矢量图的后端，字体显示效果有不少改进，但速度上慢了不少。在实验板上试了一下，性能基本上不能接受。

 

为什么不选择GTK+2.4 + DirectFB呢？GTK+在2.4到2.6之间有不少改进，大家一致认为部分改动对我们的应用有帮助。

 

GTK+2.6似乎应该是首选了，然而问题在于gdk-directfb 2.6实现得不太好。我们决定验证一下，评估其稳定性，以及修复这些问题的难度，再考虑。和一个同事一起花了两天时间去测试，去解决问题。主要问题如下：

 

字体显示有问题，根本显示不出来。由于2.4和2.8的字体显示正常，freetype、fontconfig和pango应该是没有问题的，所以把焦点锁定在GTK上。字体显示比较复杂，大致要经过下列流程：

a)         pango_renderer_draw_layout

b)        pango_renderer_draw_layout_line

c)        pango_renderer_draw_glyphs

d)        gdk_window_draw_glyphs_transformed

e)         gdk_pixmap_draw_glyphs_transformed

f)         gdk_directfb_draw_glyphs_ transformed

 

经过分析后，发现gdk_directfb_draw_glyphs_ transformed没有实现，所以画不出文字出来，考虑到我们不会用到transformed功能，就直接用gdk_directfb_draw_glyphs实现了gdk_directfb_draw_glyphs_ transformed函数。字体显示问题就解决了。

 

接下来发现TextView里选中一行文本的部分时，非选中部分显示模糊。我们知道TextView调用gtk_text_layout_draw显示文本，gtk_text_layout_draw里又调用render_para函数。在render_para里，可以看到：

 

a)         整行都被选中时，最为简单：先画高亮背景方框，再画上字体就行了。

b)        部分选中时稍麻烦一点，先按正常方式绘制，再重画选中部分，两者再迭加。关键在于设置clip_region为选中区域，否则会覆盖到不期望的区域上。

 

这些坐标和clip区域的数值都没有问题。比较2.6和2.8的代码，两者变化不大，确认不是由这些代码不同引起的。自然而然的怀疑到gdk-directfb上，后来发现在gdk_directfb_draw_glyphs函数clip的区域不对。很明显是参数传递过程出现了问题，很快查出是gdk_gc_copy里拷贝GC是没有拷贝私有数据，结果clip_region没有拷贝过来，造成剪切失败。

 

接下来的半天测试里，没有发现大的问题，所以确定采用GTK+2.6 + DirectFB方案。