從事MTK平臺的工作者很多，做高仿機的人也很多，MTK的界面變得越來越花哨，但是對于MTK平臺實現進行研究的文章并不多，希望這篇文章和以后的幾篇BLOG能為MTK的初學者帶來一些幫助。
怎么使用MTK的函數顯示圖片相信大家都會，但是圖片的解碼過程就不是人人都去研究了，由于我們做JVM移植層的需要，最近對MTK的圖形解碼進行了一些研究。
MTK在繪制圖形的時候使用的是gdi_image_codec_draw這個函數，在這個函數中，MTK會根據img_type這個參數從gdi_image_codecs這個全局數據結構數組中取得相應繪制回調函數。gdi_image_codecs全局變量在gdi_image.c文件中定義。
（1）BMP解析過程
當img_type為GDI_IMAGE_TYPE_BMP_FILE_OFFSET的時候，MTK會調用gdi_image_bmp_draw_handler作為BMP文件解析的處理函數。在這個函數中，MTK會根據程序員指定的顯示大小對bmp文件進行放大或者縮小，由于這里我們只是簡單研究一下，就不以圖片的放大或者縮小為例子了，如果要研究圖片的放大或者縮小，請各位自己研究。我們只研究不對bmp進行放大或者縮小的過程——gdi_image_bmp_draw_file函數。
gdi_image_bmp_draw_file這個函數在gdi_image_bmp.c文件中。這個函數一開始首先建立了一個比特流，在我看來就是把這個BMP文件打開，并把BMP的文件的數據放到gdi_bytestream_buffer這個全局數組中，為以后的解碼做準備。接下來大家可能就要迷糊了，MTK使用的是gdi_image_bmp_draw_internal_from_file這樣一個函數，這個函數是什么呢！說出來下一條，這個函數是個宏！確切的說這個曾經是函數調用的語句實際上被GDI_IMAGE_BMP_DRAW_INTERNAL這個宏所替代，而這個宏在gdi_image_bmp_codec.h中有一個同名函數，這樣gdi_image_bmp_draw_internal_from_file就被指示成了GDI_IMAGE_BMP_DRAW_INTERNAL。我第一次就暈菜了，搞不懂為什么MTK要費這么大勁，繞這么多彎。
GDI_IMAGE_BMP_DRAW_INTERNAL就是解碼過程，我們可以看到這里面有1，4，8，16，24，32位BMP的解碼函數，如果我們解碼的不是這些標準的BMP呢！對不起，MTK會重啟！
（2）靜態GIF圖片的解碼過程
當img_type為GDI_IMAGE_TYPE_GIF_FILE_OFFSET的時候，MTK會調用gdi_image_gif_draw_handler函數進行解碼。在這個函數中同樣分為可變大小和不可變大小，數據來源于文件還是來源與內存資源，這4種情況，我們還是只討論數據來源于文件而且不進行縮放操作的情況——gdi_image_gif_draw_file。
gdi_image_gif_draw_file這個函數有兩個分支。在整個函數的實現中，會有一個do{}while(0)的循環，在定義了硬件解碼宏之后，在硬件解碼結束以后使用一個break；語句跳出循環。軟解碼的代碼在硬解碼的代碼后面，沒有宏控制。當硬解碼宏打開后，完全靠硬解碼結束后的break來區分軟硬解碼。這樣，如果硬解碼出現問題，可能會造成嚴重的后果。我不清楚MTK為什么這樣做，可能是他們認為硬解碼的所有返回都已經處理過了，所以才使用這種方式的吧！
在6226，6228等高端的MTKCPU上，圖像都是硬解碼的。在這些CPU內部有一組專門的解碼電路來對圖形進行解碼。在硬解碼的時候，MTK最終會調用gif_decode_hw這個函數對CPU內部的寄存器進行相關的設置，最后調用GIF_START這個宏函數開始對GIF圖形進行解碼。
在6225以下的CPU中，所有的圖像都是軟解碼的，這時MTK使用了ret = gdi_image_gif_draw_file_decoders[gdi_act_layer->cf] 這個語句。gdi_image_gif_draw_file_decoders是一個函數指針數組。這個數組定義在gdi_image_gif.c中，這個數組中的元素（例如gdi_image_gif_draw_internal_from_file_8等）其實都指向GDI_IMAGE_GIF_DRAW_INTERNAL這個宏，這個宏又在Gdi_image_gif_codec.h中對應一個同名函數。好像在哪里見過哈！對！BMP就是這樣指來指去的。MTK的風格就是這樣奇怪而統一。
GDI_IMAGE_GIF_DRAW_INTERNAL就是GIF的解碼過程。 一開始，MTK向我們展示了一個catch機制，MTK把最后的2張GIF圖片保存在一個gdi_gif_cache的數據結構中，首先檢查程序員需要的是不是這兩張圖片。如果是就不用解析了，不是就要重新解析。解析的算法我們就不討論了，喜歡研究的可以看看GDI_IMAGE_GIF_CODEC這個函數的實現，GIF由于有動畫的設定，所以解析起來要比BMP復雜多了！
（3）JPEG圖片解碼過程
當img_type為GDI_IMAGE_TYPE_JPG_FILE_OFFSET的時候，MTK會調用gdi_image_jpeg_draw_handler函數進行解碼。這個函數最終會調用gdi_image_hwjpeg_draw_internal。MTK把JPEG的軟解碼和硬解碼的接口在這個函數層次統一了起來，gdi_image_hwjpeg_draw_internal會調用gdi_image_hwjpeg_start_decode，gdi_image_hwjpeg_start_decode再調用jpeg_decode_process函數。jpeg_decode_process函數再負責調用JPEG解碼核心對JPEG圖片進行解碼。最后的解碼函數為decode_jpeg_file這個函數。無論是軟解碼還是硬解碼都要調用decode_jpeg_file這個函數。在JPEG圖形解碼這部分，MTK做的還是比較符合中國工程師習慣的。
還有一點，如果我們只想取得JPEG圖像的數據，那么我們只要調用gdi_image_jpeg_draw_file_to_buffer或者gdi_image_jpeg_draw_to_buffer這兩個函數好了。我們測試過，MTK對這兩個函數的封裝，封裝的比較好。這樣就給了我們一個通過JPEG圖像傳遞某種信息的渠道。哦！搞的想干壞事一樣，不說了，不說了！
（4）PNG圖片解碼過程
當img_type為GDI_IMAGE_TYPE_PNG_FILE_OFFSET的時候，MTK會對PNG進行解碼，經過了上面的分析，我相信大家都能對MTK的圖形解碼的流程有了比較深刻的理解了，各位可以自己分析這個過程，我這邊就不贅述了！
以上我自己是對MTK圖形解碼過程的大致分析，有不當之處還希望大家能夠指正。
下一篇BLOG我準備謝謝如何在MTK平臺下建立靜態TASK，以及如何從MMITASK中接管控制權。這部分很簡單同樣是對應初學者的，希望老鳥不要拍磚！！！
MTK界面設計中消除PNG圖片的雜色背景
PNG圖片因為體積小，背景可以透明，并且由于采用矢量圖像技術可以制作無鋸齒的圓角類型的圖形等優勢。曾經在網頁和一些領域得到廣泛應用。近來可能是由于MTK的熱門提供了更多的工作機會，導致不少以前從事網站創作的美術人員也轉入到手機行業。這些同志們設計的UI充斥了大量的PNG圖片。給MTK的MMI工程師提供了不小的挑戰。
確切的說，我認為在MTK手機平臺上，PNG并不具有顯著優勢。MTK會把PNG轉化為一種BMPA的中間格式，該格式并不比同樣效果的BMP小，有時還會大上許多。至于背景透明，其實在MTK平臺，是可以把一幅BMP顯示為背景透明的。這樣PNG存在的唯一意義大約就在于顯示一些更精致的需要流線型圖像效果的UI里了。而PNG在使用過程中，在某些方面，比如疊加，比如在層中使用，往往會存在一些顯示效果不盡如人意的地方。這些原因導致許多MMI工程師不喜歡PNG，除非在非常必要的情況下，否則會直接到PNG用ASD轉為BMP使用。雖然許多時候我也不建議使用PNG，但有些必要場合，使用PNG畢竟也能為手機顯示增色不少。
一次幫客戶設計UI時，遇到在層中顯示PNG圖片顯示亂屏，圖的背景有雜色，圖標邊緣通透等問題，嚴重影響了顯示效果。本可轉為BMP重新設計，后來抱著學習的態度搜了一下52RD，竟然有人提供了一個解決了函數gdi_image_abm_set_source_layer，后來研究了一下，果然解決了這個問題。
附上樣例程序：（由于該層在移動過程中只是位置改變，然后刷在屏上，所以沒有把把創建層的代碼與使用代碼分開,圖片IMG_IDLE_TIME_BG為PNG，背景上顯示的字符也為PNG圖片,能夠消除PNG層亂屏雜色問題的函數是gdi_push_and_set_alpha_blending_source_layer，當然gdi_image_abm_set_source_layer也能達到）
void DrawDateTimeLayer(U16 x, U16 y)
{
#ifdef WIN32
buf_ptr = (PU8)malloc(180*61*2);
#else
buf_ptr = (PU8)med_alloc_ext_mem(180*61*2);
#endif
if (buf_ptr == NULL)
{
MMI_ASSERT(0);
}
gdi_layer_create_using_outside_memory(
0,
0,
180,
61,
&mylayer,
(PU8) buf_ptr,
(S32) 180*61*2);
gdi_layer_push_and_set_active(mylayer);
gdi_layer_set_position(x, y); //設置激活層的位置
gdi_push_and_set_alpha_blending_source_layer(mylayer); //把mylayer層作為blending層
gdi_layer_clear_background(GDI_COLOR_WHITE);
gdi_layer_set_source_key(TRUE, GDI_COLOR_WHITE);
gdi_image_draw_id(x, y, IMG_IDLE_TIME_BG); //繪制時間背景
gdi_pop_and_restore_alpha_blending_source_layer(); //恢復blending層
gdi_layer_pop_and_restore_active();
gdi_layer_set_blt_layer(dm_get_wallpaper_layer(), GDI_LAYER_MAIN_BASE_LAYER_HANDLE, mylayer, NULL);
gdi_layer_blt_previous(0, 0, UI_device_width-1, UI_device_height - 1);
}
樓的朋友，這些函數25平臺上是有的，在文件gdi_layer.c中可以看到該函數實現過程，如果你看不到gdi_layer.c，可能你所在的單位為保護代碼外流，對MTK代碼做了封裝，但應該不影響使用。 2樓的朋友，函數gdi_image_abm_set_source_layer用法與gdi_push_and_set_alpha_blending_source_layer一樣，傳入要設置層就可以了，不過gdi_image_abm_set_source_layer在設置新層為alpha_blending_source_layer時會返回老的alpha_blending_source_layer層的HAND，你要保存好，使用完后一定要記著把老的層還原。 3樓的朋友的回復又讓人受益良多，熟悉各種圖像格式的優缺點和MTK與之對應的API和處理機制，對我們的工作是有莫大好處的。
3樓 usstwonder 發表于 2009-6-25 10:39:00
PNG圖片可以定義alpha通道，有了alpha通道，可以定義每個像素點的透明度，能做出很炫的圖片效果來。當前MTK平臺的PNG解碼器用的是一個開源的PNG解碼器:libpng，但是mtk對libpng進行了封裝，在解碼的時候需要傳入blending層，mtk解碼的時候，會跟據圖片的alpha通道值，自動把解碼出來的像素的和blending層的像素進去混合疊加，然后把混合疊加后的效果輸出。gdi_push_and_set_alpha_blending_source_layer()是設置blending層，也就是png解碼時用來當作背景的層。