Windows Mobile的高效貼圖

Windows Mobile的高效貼圖 

原文：http://www.cppblog.com/guogangj/archive/2010/06/20/118316.html

位元影像這個概念對於電腦圖形學來說是個至關重要的概念，我們在螢幕上看到的任何東西，對電腦來說，其實都是位元影像，簡單地說，無論你是想顯示文字，還是線條，抑或bmp，png，jpg和gif等影像檔，最終都是要直接或間接轉變為電腦顯示裝置所認識的位元影像，才能顯示在螢幕上。

我最近接手了一個項目，是Windows Mobile平台的，主要做UI美化，貼圖是其中的一大塊，我遇到的最大的問題就是貼圖的效率問題，如何將一張記憶體裡的圖片高效繪製出來，實現平滑流暢的UI動畫效果。我嘗試了許多辦法，甚至DirectDraw，但我發覺在硬體不支援的情況下，DirectDraw除了讓代碼變得更複雜之外，沒有任何優點。好，接下去我們來分析一下如何盡量發揮GDI的威力。

跟貼圖相關的函數有幾個：
BitBlt：最基本的塊傳輸函數。
StretchBlt：比同BitBlt，它支援映像的展開和壓縮，當不需要展開和壓縮時候，它的效果和BitBlt並無二致。
TransparentBlt：比同StretchBlt，它多了個“摳色”（Color Keying）功能，能把某種顏色或者某個範圍的顏色摳去而不作塊傳輸處理，以此來繪製不規則映像。
AlphaBlend：比同StretchBlt，它支援Alpha混合，即“半透明”效果，效果比簡單的“摳色”更好。

這幾個函數是一個比一個強，但也意味著效率一個比一個低，總體上看差不多是這樣的，運算量越大，當然就越慢，但測試下來發覺這其實並不絕對，後面會提到。

瞭解了這幾個函數之後，我們開始載入一張圖片來觀察效果，我準備的是一張320*320的png圖片，利用Windows Mobile 6.0提供的IImage介面來載入它，並把它轉變為位元影像，獲得HBITMAP。載入png的代碼可以通過搜尋引擎搜尋“IImage用法”等關鍵詞來擷取，此處略過。

載入好圖片後，建立一個和裝置顯示裝置相容的DC（Device Context），選入上面載入的位元影像，用BitBlt繪製，代碼如下（為簡潔起見，只貼出關鍵代碼，並且不考慮資源釋放）：
HDC hWndDC = GetDC(hWnd);
HDC hMemDC = CreateCompatibleDC(hWndDC);
SelectObject(hMemDC, hBitmap); //hBitmap是前面載入的圖片
BitBlt(hWndDC, 0, 0, iWidth, iHeight, hMemDC, 0, 0, SRCCOPY);

我們通過添加一些debug代碼來觀察BitBlt的執行時間，在我的模擬器上大約是50 - 60ms，我發覺這個速度並不快，按道理說，BitBlt應該可以在極短的時間之內完成的（1 - 2ms），也只有這樣才能實現“流暢”的UI動畫效果，否則圖一旦多起來，豈不是更慢。

我嘗試修改BitBlt的最後一個參數，我發覺換成NOTSRCCOPY，速度更慢，變成了70多ms，說明運算量更大了，這不是簡單的記憶體拷貝；而當我把最後一個參數換成BLACKNESS或者WHITENESS的時候，速度則很快，1ms-2ms即可完成，很顯然，對BitBlt來說，把目標全部置為黑色或者白色，運算量遠少於像素傳送。在實驗的時候把BitBlt替換為另外的幾個函數，效果和預期的相差不大，如果映像需要展開，則執行得更慢一些，但如果映像不是展開，而是壓縮，即縮小顯示，執行速度居然比較快，有些意外，這是因為壓縮後映像變小，需要傳輸的像素變少的緣故。

我考慮如何提高繪圖效率，經過很多次嘗試，終於有所突破，我最後發現：如果先把位元影像存放在一個和DC相容的位元影像中，再用這個位元影像對目標裝置進行像素傳輸，速度十分理想。代碼：
HDC hWndDC = GetDC(hWnd);
HDC hMemDC = CreateCompatibleDC(hWndDC);
HDC hMemDCToLoad = CreateCompatibleDC(hWndDC);
HBITMAP hMemBmp = CreateCompatibleBitmap(hWndDC, iWidth, iHeight); // The compatible bitmap
HGDIOBJ hOldBmp = SelectObject(hMemDC, hMemBmp);
SelectObject(hMemDCToLoad, hBitmap);
BitBlt(hMemDC, 0, 0, iWidth, iHeight, hMemDCToLoad, 0, 0, SRCCOPY); //Do this in initialization
BitBlt(hWndDC, 0, 0, iWidth, iHeight, hMemDC, 0, 0, SRCCOPY); //This BitBlt's speed is very fast

第一次調用BitBlt，可以看作是初始化，我們計算第二個BitBlt的耗時，只有1 - 2ms，非常不錯，經過分析，我認為原因應該是這樣（不一定全對，如有不妥請讀者指出）：

只有在位元影像格式完全一致的情況下，BitBlt才能執行真正的記憶體拷貝，否則是要經過轉換的，轉換是需要消耗CPU時間的，所以慢。

那如何知道位元影像的格式呢？用GetObject可以看出來：

如所示，bmp是從png檔案載入進來的位元影像的資訊，而bmp2是用CreateCompatibleBitmap建立的位元影像的資訊，從這我們能看到，前者是24bit位元影像，即一個像素用3個位元組表示，而後者是16bit位元影像，一個像素用兩個位元組來表示，這個BitBlt執行過程中，就需要轉換了，因此耗時。而實際上位元影像的差別可能比這個還要複雜些，如果再討論裝置無關位元影像，那就說不完了……

總而言之，為了提高效率，我們要想方設法把載入進來的位元影像轉變為裝置相容位元影像，繪製的時候直接BitBlt這些裝置相容位元影像，來實現位元影像的高效繪製。

前面討論的主要是BitBlt，那對於別的幾個Blt函數呢？我都嘗試過了，除了AlphaBlend之外，相容位元影像到裝置的Blt速度上都有顯著的提高，而AlphaBlend則無法正常工作，因為相容位元影像不帶Alpha通道，而AlphaBlend貌似需要32bit的ARGB格式的位元影像方可正常工作，這個問題我思考了好久都無解，如果哪位讀者對提高AlphaBlend的工作效率有心得，不妨跟我聯絡下，我正急需這方面的技術資料。

因此，我給出這樣的結論，階段性結論：從檔案（或資源）載入位元影像後，把位元影像轉為裝置相容位元影像，這樣使得BitBlt在執行SRCCOPY的時候直接使用記憶體拷貝，速度很快，即便需要展開壓縮或者摳色等運算，使用相容位元影像的速度也是相當不錯的，而使用AlphaBlend的時候，如果需要較高的效率，就應從設計上避免繪製大幅位元影像，改用小幅位元影像，在不必要對每一幀都執行Alpha混合的時候，就避免執行，以免影響畫面的流暢性。