分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！
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
方案。
給我老師的人工智慧教程打call！
GTK 2 6 DirectFB的幾個問題
gtk 2.6 directfb 的幾個問題 經過幾番周折，終於確定採用 gtk 2.6 directfb 方案。之所以不選擇 gtk 2.8 tinyx 主要是出於硬體成本上的考慮，tinyx 包括xlib 等庫檔案 要佔 4m flash 空間，加上視窗管理器還要耗好幾m的 ram，同時程序間通...
GTK 2 6 DirectFB的幾個問題
gtk 2.6 directfb的幾個問題 經過幾番周折，終於確定採用gtk 2.6 directfb方案。之所以不選擇gtk 2.8 tinyx主要是出於硬體成本上的考慮，tinyx 包括xlib等庫檔案 要佔4m flash空間，加上視窗管理器還要耗好幾m的ram，同時程序間通訊過於頻繁，效能上...
幾個問題，別人問的
udp丟包，丟的是啥？rtp頭？udp頭？資料幀？還是完整包全丟？tcp和udp丟包的區別以及如何通過二進位制資料或者抓包檔案快速區別 udp丟包和tcp丟包的區別啊？udp丟包，丟的是rtp頭？udp頭？udp包？還是資料流？如何判斷丟包是否是由擁塞控制導致？還是包大小導致？udp如何做資料分頁 ...