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方案。