CreateCompatibleBitmap 的使用

標籤：

函數功能：該函數建立與指定的裝置環境相關的裝置相容的位元影像。

　　函數原型：HBITMAP CreateCompatibleBitmap(HDC hdc,int nWidth,int nHeight)；

　　參數：

　　hdc：裝置環境控制代碼。

　　nWidth：指定位元影像的寬度，單位為像素。

　　nHeight：指定位元影像的高度，單位為像素。

　　傳回值：如果函數執行成功，那麼傳回值是位元影像的控制代碼；如果函數執行失敗，那麼傳回值為NULL。若想擷取更多錯誤資訊，請調用GetLastError。

　　備忘：由CreateCompatibleBitmap函數建立的位元影像的顏色格式與由參數hdc標識的裝置的顏色格式匹配。該位元影像可以選入任意一個與原裝置相容的記憶體裝置環境中。由於記憶體裝置環境允許彩色和單色兩種位元影像。因此當指定的裝置環境是記憶體裝置環境時，由CreateCompatibleBitmap函數返回的位元影像格式不一定相同。然而為非記憶體裝置環境建立的相容位元影像通常擁有相同的顏色格式，並且使用與指定的裝置環境一樣的色彩調色盤。

　　速查：Windows NT：3.1及以上版本；Windows：95及以上版本；Windows CE：1.0及以上版本；標頭檔：wingdi.h；庫檔案：gdi32.lib。

　　PS:需要與CreateCompatibleDC配合使用

 

 

 

物理HDC 裝置底層會擁有顯存等資源,但是相容DC並沒有給映像像素提供記憶體空間,因此相容DC總是和BITMAP配合使用,這樣一來,相容DC就利用BITMAP的映像像素資料空間給自己提供類似於顯存的記憶體空間.

這樣有很多好處,以來我們可以在載入圖片後,在圖片上利用DC的各種繪圖功能.請看如下樣本:

相容DC在建立之初,只有1*1像素的尺寸,SelectObject選擇bitmap以後才可以進行繪圖.

記憶體DC的可見地區是簡單的地區,不像物理DC可見地區可能被其他視窗覆蓋而產生複雜的可見地區.由於DC的任何繪圖都需要考慮在可見地區內繪圖,絕對不能超出可見地區的範圍.因此每個GDI繪圖輸出最終都需要和構成複雜可見地區的每一個巨型地區進行剪裁輸出,因此物理DC的繪圖效果會比相容DC速度慢一些.這也就是我們經常用相容DC進行雙緩衝輸出的一個原因

HDC hdc=GetDC(hwnd);
HDC memdc=CreateCompatibleDC(hdc);
RECT rc;
BITMAP bmp;
HBITMAP holdbmp,hbmp=LoadBitmap(hInstDVBRes,MAKEINTRESOURCE(IDB_CLOCK));//從資源載入位元影像
holdbmp=(HBITMAP)SelectObject(memdc,hbmp);//這裡把hbmp的位元影像選擇到相容DC memdc,之後這個相容DC就擁有和
//hbmp同樣大小的繪圖區域,注意超出位元影像返回的GDI輸出都是無效的.
GetObject(hbmp,sizeof(BITMAP),&bmp);//這裡擷取位元影像的大小資訊,事實上也是相容DC繪圖輸出的範圍
SetRect(&rc,0,0,bmp.bmWidth,bmp.bmHeight);
DrawText(memdc,"Center Line Text" -1,&rc,DT_VCENTER|DT_SINGLELINE|DT_CENTER);//在相容DC中間位置輸出字串
//這樣以來我們就相當於把hbmp這個位元影像加上了文字標註,我們可以把這個增加了文字標註的位元影像儲存起來.一個簡單的影像處理基本就OK了.
SelectObject(memdc,holdbmp);//複原相容DC資料.
DeleteDC(memdc);

***********************************************************

 

 

首先現象是這樣的：   
  我的程式突然有一天，一個Create出來的視窗畫不出東西，開了天窗！跟進去一看，是調用CBitmap::CreateBitmap失敗（傳回值為FALSE）。用GetLastError查到的原因是“ERROR_NOT_ENOUGH_MEMORY”。   
  很奇怪，這個view的代碼我並沒有動啊！我試著改成CBitmap::CreateCompatibleBitmap，好了！算了，不管了，就這麼著吧～   
  誰知，過了些時日，別的視窗又開天窗了！   
  這次我把CreateBitmap改成CreateCompatibleBitmap，也不是每次都成功，時不時的就會建立失敗！   
    
  查msdn，關於CreateBitmap   API有如下這一段話：   
  The   CreateBitmap   function   can   be   used   to   create   color   bitmaps.     
  However,   for   performance   reasons   applications   should   use   CreateBitmap   to   create   monochrome   bitmaps   and   CreateCompatibleBitmap   to   create   color   bitmaps.     
  Whenever   a   color   bitmap   returned   from   CreateBitmap   is   selected   into   a   device   context,   the   system   checks   that   the   bitmap   matches   the   format   of   the   device   context   it   is   being   selected   into.     
  Because   CreateCompatibleBitmap   takes   a   device   context,   it   returns   a   bitmap   that   has   the   same   format   as   the   specified   device   context.     
  Thus,   subsequent   calls   to   SelectObject   are   faster   with   a   color   bitmap   from   CreateCompatibleBitmap   than   with   a   color   bitmap   returned   from   CreateBitmap.   
    
  這段話看著挺繞，說CreateCompatibleBitmap   API比CreateBitmap   API的效率更高一些。那麼，我的問題之一是：   
  CBitmap的這兩個屬性，是否也如API一樣，CreateCompatibleBitmap比CreateBitmap的效率高？？   
    
  我的問題之二：搜了一下，我的程式裡，有二十多處地方（17個視窗）調用CreateBitmap，10處地方調用CreateCompatibleBitmap，且這些佔用bitmap的視窗只在最後退出的時候才銷毀。有經驗的同仁看看，調用的地方是不是太多了？如果都換成CreateCompatibleBitmap，資源佔用情況是否會有所改觀？  

——————————————————————————

在Create之前，都有類似如下的代碼：   
  if(NULL   !=   m_pMemBitmap)   
  {   
              m_pMemBitmap->DeleteObject();   
              delete   m_pMemBitmap;   
  }   
  m_pMemBitmap   =   new   CBitmap;   
  BOOL   b   =   m_pMemBitmap->CreateCompatibleBitmap(pDC,rcClient.Width(),rcClient.Height());   
  感覺沒有什麼可泄漏的。   
    
  ==================>   
    
  暈,真是這樣寫的話就泄露了,而且露的很厲害   
  if(NULL   !=   m_pMemBitmap)   
  {   
              m_pMemBitmap->DeleteObject();   
              delete   m_pMemBitmap;   
              m_pMemBitmap   =   NULL;//光delete,   m_pMemBitmap   是不會為NULL的   
  }

 

此文摘自：http://fengqing888.blog.163.com/blog/static/3301141620091019104353119/，因為講的實在太好了，所以就忍不住粘貼過來了。感謝這哥們

CreateCompatibleBitmap 的使用