端中的顯示與調(diào)色板管理實(shí)戰(zhàn))
簡(jiǎn)介面向Windows平臺(tái)C開(kāi)發(fā)者的商業(yè)編程源碼包重點(diǎn)解決MDI多文檔界面中加載、解析與顯示位圖的問(wèn)題適合學(xué)習(xí)圖形設(shè)備接口底層機(jī)制的開(kāi)發(fā)者。示例工程展示了完整流程先解析文件頭和信息頭理解位圖結(jié)構(gòu)再按從下到上的掃描行處理像素?cái)?shù)據(jù)對(duì)八位及以下顏色深度自動(dòng)構(gòu)建調(diào)色板將索引值轉(zhuǎn)為RGB顏色最后通過(guò)設(shè)備無(wú)關(guān)位圖與設(shè)備上下文配合將圖像繪制到MDI客戶(hù)區(qū)。工程基于MFC文檔視圖架構(gòu)演示了主框架、文檔類(lèi)、視圖類(lèi)與MDI客戶(hù)區(qū)的協(xié)作關(guān)系。壓縮包共29個(gè)文件以頭文件、C源文件和資源腳本為主兼顧位圖圖標(biāo)素材與編譯產(chǎn)物EXE整體僅61KB結(jié)構(gòu)緊湊便于查閱代碼結(jié)構(gòu)清晰注釋風(fēng)格貼近商業(yè)項(xiàng)目。目前已有120人學(xué)習(xí)下載。通過(guò)分析源碼可加深對(duì)24位真彩與8位索引色位圖存儲(chǔ)差異的認(rèn)識(shí)掌握設(shè)備無(wú)關(guān)位圖創(chuàng)建、設(shè)備上下文選擇與顯示輸出的關(guān)鍵接口用法并學(xué)習(xí)窗口消息處理、顏色適配、內(nèi)存釋放等商業(yè)級(jí)編程技巧對(duì)構(gòu)建穩(wěn)定高效的桌面應(yīng)用具有實(shí)際參考價(jià)值也是深入理解Windows位圖格式的良好范例。1. 這個(gè)源碼包到底在解決什么問(wèn)題位圖、調(diào)色板與 MDI 客戶(hù)端的三方協(xié)作如果你是做過(guò) Win32 界面維護(hù)的老工程師看到bmp_in_mdiclient.zip這個(gè)文件名大概會(huì)立刻意識(shí)到這不是一個(gè)花哨的 demo而是 Windows 編程里一個(gè)長(zhǎng)期存在的經(jīng)典組合——把位圖裝進(jìn) MDI 客戶(hù)區(qū)同時(shí)正確處理調(diào)色板。它是“商業(yè)編程-源碼”這個(gè)序列里少有的、把 GDI 底層機(jī)制串起來(lái)的范例文件讀盤(pán)、DIB 解析、顏色表映射、MDI 子窗口注冊(cè)、繪制與消息循環(huán)。這套代碼適合誰(shuí)兩類(lèi)人。一類(lèi)是維護(hù)存量系統(tǒng)的開(kāi)發(fā)者手里還跑著 Windows 2000/XP 時(shí)代用 Visual C 或 Delphi 寫(xiě)的老 MFC/Win32 程序界面里嵌著大量 256 色位圖另一類(lèi)是剛接觸 Windows GDI 底層編程的學(xué)習(xí)者想搞清楚「為什么位圖在不同機(jī)器上顏色不一樣」「調(diào)色板到底管不管用」。本文會(huì)順著這個(gè)源碼包的核心思路把 BMP 文件結(jié)構(gòu)、MDI 客戶(hù)端顯示、調(diào)色板同步這三塊拆開(kāi)講最后給出一份能直接落地的改進(jìn)清單。2. 先看懂 BMP 文件里的顏色黑匣子文件頭、信息頭與調(diào)色板的讀取順序2.1 BMP 文件在磁盤(pán)上的實(shí)際布局為什么調(diào)色板位圖要單獨(dú)處理很多從 C# 或 Java 轉(zhuǎn)過(guò)來(lái)寫(xiě) Win32 的人第一次讀 BMP 文件時(shí)都會(huì)犯同一個(gè)錯(cuò)用fread一次性把整個(gè)文件讀進(jìn)緩沖區(qū)然后直接把緩沖區(qū)指針交給StretchDIBits。這在 24 位真彩位圖上常常能僥幸跑通因?yàn)檎娌?BMP 的信息頭后面直接就是像素?cái)?shù)據(jù)沒(méi)有顏色表但換成一個(gè) 8 位 BMP屏幕就會(huì)花成一片。原因是文件中間夾著一塊大小固定的顏色表你跳過(guò)了它像素?cái)?shù)據(jù)就整體偏移了。標(biāo)準(zhǔn)的 BMP 文件布局是三段式先是BITMAPFILEHEADER14 字節(jié)然后是BITMAPINFOHEADER40 字節(jié)起最后是實(shí)際數(shù)據(jù)區(qū)。數(shù)據(jù)區(qū)里是否包含顏色表取決于信息頭里的biBitCount。biBitCount為 8、4、1 時(shí)像素值只是調(diào)色板索引真正的顏色存在緊挨信息頭后面的 RGBQUAD 數(shù)組里為 16、24、32 時(shí)像素直接攜帶顏色分量沒(méi)有顏色表。這個(gè)字段是整個(gè)讀取邏輯的分岔點(diǎn)。// 讀取BMP文件并提取信息頭與調(diào)色板只讀關(guān)鍵結(jié)構(gòu) BITMAPFILEHEADER bf; BITMAPINFOHEADER bi; DWORD dataOffset; FILE* fp fopen(szPath, rb); if (!fp) return FALSE; fread(bf, sizeof(BITMAPFILEHEADER), 1, fp); fread(bi, sizeof(BITMAPINFOHEADER), 1, fp); dataOffset bf.bfOffBits; // 像素?cái)?shù)據(jù)的起始偏移通常在顏色表后 if (bi.biBitCount 8) { // 8位及以下位圖必須讀到顏色表否則后面的像素?zé)o法解碼 DWORD clrCount bi.biClrUsed ? bi.biClrUsed : (1 bi.biBitCount); RGBQUAD palette[256]; fread(palette, sizeof(RGBQUAD), clrCount, fp); // 這里可以把palette轉(zhuǎn)成LOGPALETTE供CreatePalette使用 } fclose(fp);這段代碼的關(guān)鍵在一個(gè)細(xì)節(jié)顏色表數(shù)量不是永遠(yuǎn)等于1 biBitCount。當(dāng)biClrUsed不為 0 時(shí)文件里只保存了實(shí)際用到的顏色項(xiàng)一般常見(jiàn)的情況是biClrUsed 0表示顏色表填滿(mǎn)了 256 項(xiàng)。你如果忽略biClrUsed在遇到優(yōu)化過(guò)的文件時(shí)要么讀多、要么讀少后面繪制時(shí) GDI 會(huì)以信息頭聲明的顏色數(shù)為準(zhǔn)兩邊對(duì)不上就會(huì)偏色或干脆畫(huà)不出東西。2.2 調(diào)色板位圖與真彩位圖的組織差異像素?cái)?shù)據(jù)里的索引到底是什么調(diào)色板位圖里存的是索引不是顏色。這句話(huà)值得反復(fù)強(qiáng)調(diào)。8 位 BMP 的每個(gè)像素占 1 個(gè)字節(jié)值域 0 到 255這個(gè)值對(duì)應(yīng)顏色表中第 N 個(gè) RGBQUAD 的顏色。4 位圖一個(gè)字節(jié)裝兩個(gè)像素高位是前一個(gè)像素的索引低位是后一個(gè)1 位圖一個(gè)字節(jié)裝 8 個(gè)像素每個(gè)像素只占 1 bit。處理低位圖時(shí)要按位拆開(kāi)再查顏色表否則會(huì)把兩個(gè)像素當(dāng)成一個(gè)去顯示。真彩位圖則完全繞開(kāi)調(diào)色板。24 位每像素 3 字節(jié)按 BGR 順序存儲(chǔ)32 位多一個(gè)保留字節(jié)常用于帶 alpha 通道的界面素材。這里有個(gè)老手都熟悉的反直覺(jué)點(diǎn)文件里是 BGR但 GDI 的RGBQUAD結(jié)構(gòu)體字段名是rgbBlue / rgbGreen / rgbRed所以直接讀出來(lái)就是對(duì)的反而是你自己去「糾正」字節(jié)序會(huì)出錯(cuò)。調(diào)色板在 MDI 程序里還有一個(gè)特殊地位它不是只服務(wù)于當(dāng)前窗口而是由系統(tǒng)統(tǒng)一管理。Windows 在 256 色模式下只有一個(gè)系統(tǒng)調(diào)色板所有窗口共享 20 個(gè)系統(tǒng)保留色剩下 236 個(gè)可由前臺(tái)窗口自由映射。這就是為什么同一個(gè)位圖在一個(gè)程序里顏色正常切到另一個(gè)程序再切回來(lái)就變色——不是文件壞了是調(diào)色板被搶占后沒(méi)恢復(fù)。2.3 低位圖在 MDI 場(chǎng)景里的顯示成本為什么不能直接用 BitBlt把調(diào)色板位圖加載成HBITMAP之后很多初學(xué)者會(huì)順手用BitBlt往窗口上貼。這在真彩模式下沒(méi)問(wèn)題在 256 色模式下會(huì)翻車(chē)因?yàn)槟阗N的是位圖索引而B(niǎo)itBlt默認(rèn)按系統(tǒng)調(diào)色板解釋顏色。正確的做法是用CreateDIBitmap把 DIB 轉(zhuǎn)成 DDB 并關(guān)聯(lián)位圖自身的調(diào)色板或者干脆保持 DIB 格式用StretchDIBits直接畫(huà)。從源碼包的名字bmp_in_mdiclient推斷它的核心路徑也走的是 DIB 方案解析出來(lái)的調(diào)色板交給CreatePalette像素?cái)?shù)據(jù)連同BITMAPINFO保留在內(nèi)存中繪制時(shí)用StretchDIBits一次完成調(diào)色板映射和伸縮。這個(gè)選擇比 DDB 方案更穩(wěn)因?yàn)?DDB 是設(shè)備相關(guān)的換機(jī)器、換顯卡、換色彩模式都可能失效而 DIB 是設(shè)備無(wú)關(guān)的同一份內(nèi)存數(shù)據(jù)在任何機(jī)器上都能按BITMAPINFO里的參數(shù)解釋。3. 在 MDI 客戶(hù)區(qū)顯示位圖從 LoadImage 到 StretchDIBits 的完整代碼路徑3.1 先搭好 MDI 的架子框架窗口、客戶(hù)端窗口與子窗口的關(guān)系MDI 程序的窗口層級(jí)是三層框架窗口Frame、MDI 客戶(hù)端窗口MDIClient、子窗口Child。bmp_in_mdiclient要做的是在子窗口的客戶(hù)區(qū)里顯示位圖而子窗口本身在 MDI 客戶(hù)區(qū)里可以被拖動(dòng)、最大化和層疊。這三者的消息傳遞順序決定了調(diào)色板通知會(huì)先到框架窗口再?gòu)腤M_MDINEXT等廣播消息擴(kuò)散到子窗口。創(chuàng)建 MDI 子窗口時(shí)框架窗口的WM_CREATE里必須調(diào)用DefFrameProc并注冊(cè)MDICLIENT窗口類(lèi)否則子窗口無(wú)法建立。常見(jiàn)的錯(cuò)誤是把 MDI 客戶(hù)端當(dāng)成普通子窗口處理結(jié)果CreateMDIWindow一直失敗。子窗口類(lèi)需要注冊(cè)自己的窗口過(guò)程WM_PAINT里拿到的hdc是子窗口的設(shè)備上下文繪制范圍是子窗口客戶(hù)區(qū)不是整個(gè)屏幕。// 注冊(cè)MDI子窗口類(lèi)簡(jiǎn)化版 WNDCLASS wc {0}; wc.lpfnWndProc ChildWndProc; wc.hbrBackground (HBRUSH)(COLOR_WINDOW 1); wc.lpszClassName BmpChildClass; RegisterClass(wc); HWND hClient GetParent(hwndFrame); // 框架窗口的客戶(hù)區(qū)是MDIClient CLIENTCREATESTRUCT ccs { hInst, 0 }; HWND hChild CreateMDIWindow( BmpChildClass, // 子窗口類(lèi)名 szFileName, // 標(biāo)題顯示文件名 WS_CHILD | WS_VISIBLE | WS_THICKFRAME, 10, 10, 640, 480, // 初始位置與尺寸 hClient, // 父窗口必須是MDIClient hInst );參數(shù)說(shuō)明CreateMDIWindow的父窗口必須是 MDIClient 句柄而不是框架窗口句柄這一點(diǎn)新手最容易搞反。WS_THICKFRAME給了子窗口可縮放邊框縮放后WM_SIZE會(huì)通知子窗口重算顯示區(qū)域如果你忘了在子窗口注冊(cè)類(lèi)時(shí)指定合適的背景畫(huà)刷縮放過(guò)程中會(huì)出現(xiàn)大量閃爍殘影。3.2 用 LoadImage 把位圖文件裝進(jìn)內(nèi)存參數(shù)與兩種數(shù)據(jù)源的取舍MDI 子窗口知道文件路徑后加載位圖有兩條路線。一條是用LoadImage加載成HBITMAP好處是代碼量少系統(tǒng)自動(dòng)解析文件類(lèi)型壞處是拿不到調(diào)色板數(shù)組不方便做 256 色下的精細(xì)調(diào)色板管理。另一條是手動(dòng)按第 2 章的解析流程讀取 DIB 數(shù)據(jù)雖然繁瑣但像素和調(diào)色板都在你手里繪制和顏色管理最靈活。源碼包若走「DIB 全線手動(dòng)」的路線那LoadImage可能只出現(xiàn)在菜單圖標(biāo)這類(lèi)附屬資源里主位圖推薦讀完文件頭后直接用SetDIBitsToDevice或StretchDIBits繪制。不過(guò)我還想提一個(gè)常見(jiàn)做法很多存量程序員圖省事先用LoadImage加載再用GetObject拿BITMAP結(jié)構(gòu)里的寬度高度繪制時(shí)發(fā)現(xiàn)沒(méi)有調(diào)色板信息最后還是回頭寫(xiě) DIB 解析。既然最終都要解析不如一步到位。// 用LoadImage加載位圖適用于加載ICO或臨時(shí)預(yù)覽 HBITMAP hBmp (HBITMAP)LoadImage( hInstance, szFullPath, IMAGE_BITMAP, 0, 0, // 寬高傳0表示按文件原始尺寸加載 LR_LOADFROMFILE // 必須加上否則默認(rèn)從exe資源中查找 );參數(shù)說(shuō)明LR_LOADFROMFILE是坑最多的一個(gè)標(biāo)志。不加它系統(tǒng)會(huì)去模塊的資源段里按szFullPath查找結(jié)果必然是返回 NULL。cx和cy為 0 時(shí)按文件原尺寸加載如果你指定了非零值LoadImage會(huì)做一次縮放但這個(gè)縮放質(zhì)量不如StretchDIBits可控放大的位圖會(huì)產(chǎn)生明顯的像素格點(diǎn)。3.3 StretchDIBits 繪制與縮放8 個(gè)關(guān)鍵參數(shù)一次說(shuō)清繪制是bmp_in_mdiclient的核心動(dòng)作。子窗口的WM_PAINT里拿到PAINTSTRUCT后用StretchDIBits把 DIB 畫(huà)到子窗口客戶(hù)區(qū)。這個(gè)函數(shù)有 11 個(gè)參數(shù)真正容易出錯(cuò)的只有 4 組目標(biāo)矩形x, y, cx, cy、源矩形xSrc, ySrc, cxSrc, cySrc、DIB 數(shù)據(jù)指針和顏色模式。源矩形寬高用BITMAPINFOHEADER里的biWidth和biHeight計(jì)算但要注意高度有正負(fù)之分。biHeight為正表示自底向上存儲(chǔ)讀文件后像素?cái)?shù)據(jù)要倒著掃為負(fù)才表示自頂向下。很多程序在掃描行序上翻車(chē)顯示出來(lái)的圖上下顛倒就是這個(gè)符號(hào)沒(méi)有處理。// 在MDI子窗口的WM_PAINT里繪制DIB case WM_PAINT: { PAINTSTRUCT ps; HDC hdc BeginPaint(hwnd, ps); if (g_pBits g_pBMI) { int destX 0, destY 0; int destW min(rect.right, g_bmpWidth); // 按客戶(hù)區(qū)比例截?cái)?int destH min(rect.bottom, g_bmpHeight); StretchDIBits( hdc, // 目標(biāo)設(shè)備上下文 destX, destY, destW, destH,// 目標(biāo)矩形客戶(hù)區(qū)左上角開(kāi)始 0, 0, g_pBMI-bmiHeader.biWidth, abs(g_pBMI-bmiHeader.biHeight), // 源矩形高度取絕對(duì)值 g_pBits, // 像素?cái)?shù)據(jù)指針 g_pBMI, // BITMAPINFO含調(diào)色板表 DIB_RGB_COLORS, // 顏色模式用邏輯調(diào)色板索引 SRCCOPY // 光柵操作碼直接拷貝 ); } EndPaint(hwnd, ps); break; }DIB_RGB_COLORS這個(gè)參數(shù)的語(yǔ)義要認(rèn)真理解它表示 DIB 數(shù)據(jù)里的顏色表是 RGB 值GDI 會(huì)自己完成匹配。如果你在低色彩模式下DIB_RGB_COLORS會(huì)結(jié)合系統(tǒng)調(diào)色板自動(dòng)映射如果 DIB 里帶著 LOGPALETTE你要用DIB_PAL_COLORS此時(shí) DIB 數(shù)據(jù)里的顏色表被解釋為 16 位索引數(shù)組指向當(dāng)前選入 DC 的邏輯調(diào)色板。兩者一旦混用輕則偏色重則整屏花掉。3.4 源碼剖析從打開(kāi)文件到子窗口重繪的調(diào)用鏈把這幾個(gè)環(huán)節(jié)串起來(lái)bmp_in_mdiclient的典型調(diào)用鏈?zhǔn)沁@樣的菜單項(xiàng)「打開(kāi)位圖」觸發(fā)GetOpenFileName彈文件對(duì)話(huà)框確認(rèn)后由框架窗口WM_COMMAND處理讀取路徑后創(chuàng)建新的 MDI 子窗口子窗口的WM_CREATE里完成 DIB 解析、調(diào)色板創(chuàng)建和像素?cái)?shù)據(jù)讀取最后觸發(fā)一次InvalidateRect讓W(xué)M_PAINT把圖畫(huà)出來(lái)。之后每次子窗口被遮擋再露出系統(tǒng)自動(dòng)補(bǔ)發(fā)WM_PAINT繪制邏輯不變。這個(gè)調(diào)用鏈里藏著一個(gè)決定成敗的細(xì)節(jié)DIB 解析最好放在WM_CREATE而不是WM_PAINT里做。因?yàn)閃M_PAINT在窗口重繪時(shí)會(huì)被頻繁觸發(fā)每次重新讀磁盤(pán)和解析顏色表程序會(huì)卡得沒(méi)法用。正確做法是解析一次把BITMAPINFO、像素指針和調(diào)色板句柄存成全局或窗口實(shí)例數(shù)據(jù)WM_PAINT只負(fù)責(zé)繪制。文件讀完后的清理也一樣重要。fread得到的緩沖區(qū)、CreatePalette創(chuàng)建的調(diào)色板句柄都要在WM_CLOSE或WM_DESTROY里釋放。調(diào)色板句柄不釋放程序每開(kāi)一張圖就泄漏 256 項(xiàng)系統(tǒng)資源開(kāi)幾十張圖之后系統(tǒng)調(diào)色板就會(huì)被耗干其他程序的顏色全部錯(cuò)亂這是 GDI 編程里最難排查的資源泄漏之一。4. 調(diào)色板管理SelectPalette 與 RealizePalette 的配合以及顏色閃爍的真相4.1 系統(tǒng)調(diào)色板在 256 色模式下是怎么運(yùn)作的236 個(gè)可用顏色的分配機(jī)制在 256 色顯示模式下Windows 系統(tǒng)維護(hù)一個(gè) 256 項(xiàng)的調(diào)色板。其中 10 項(xiàng)是系統(tǒng)保留色永遠(yuǎn)不變通常是黑色、白色、灰色系等基本色另外 10 項(xiàng)用于系統(tǒng)界面標(biāo)題欄、菜單等。真正可以給應(yīng)用用的有 236 項(xiàng)。前臺(tái)窗口可以通過(guò)RealizePalette把這 236 項(xiàng)全部映射成自己調(diào)色板里的顏色而所有后臺(tái)窗口只能部分映射映射不上的顏色由系統(tǒng)用最接近的顏色替代。這就是bmp_in_mdiclient為什么要單獨(dú)管理調(diào)色板的原因。顯示一張 256 色照片98% 的顏色都落在保留色之外如果你不把位圖的調(diào)色板 Realize 到系統(tǒng)調(diào)色板里整張圖會(huì)灰蒙蒙的顏色完全不對(duì)。源碼包里調(diào)色板相關(guān)代碼的占比往往比顯示代碼還大因?yàn)?MDI 多窗口環(huán)境下每個(gè)子窗口都想搶那 236 個(gè)顏色槽協(xié)調(diào)不好就互相頂?shù)簟?.2 三個(gè)關(guān)鍵消息的配合順序WM_PALETTECHANGED 與 WM_QUERYNEWPALETTE 的角色當(dāng)一個(gè) MDI 程序里有多個(gè)子窗口每個(gè)子窗口各顯示一張不同色調(diào)的位圖它們之間就產(chǎn)生了調(diào)色板競(jìng)爭(zhēng)。Windows 解決這個(gè)競(jìng)爭(zhēng)靠?jī)深?lèi)消息WM_QUERYNEWPALETTE發(fā)給即將獲得前臺(tái)焦點(diǎn)的窗口WM_PALETTECHANGED廣播給所有窗口通知它們系統(tǒng)調(diào)色板已經(jīng)被改變。這兩個(gè)消息都要處理缺一個(gè)就會(huì)花屏。重點(diǎn)說(shuō)順序。窗口從后臺(tái)切到前臺(tái)時(shí)系統(tǒng)先發(fā)WM_QUERYNEWPALETTE窗口在這里調(diào)用SelectPalette和RealizePalette如果確實(shí)改變了系統(tǒng)調(diào)色板返回 TRUE。隨后系統(tǒng)廣播WM_PALETTECHANGED給所有頂層窗口每個(gè)收到消息的窗口包括剛才那個(gè)前臺(tái)窗口都要判斷wParam是不是自己如果是自己就不用重復(fù)處理了。// 處理調(diào)色板消息前臺(tái)與后臺(tái)窗口的兩種響應(yīng) case WM_QUERYNEWPALETTE: { HDC hdc GetDC(hwnd); HPALETTE hOldPal SelectPalette(hdc, g_hPalette, FALSE); UINT changed RealizePalette(hdc); SelectPalette(hdc, hOldPal, FALSE); ReleaseDC(hwnd, hdc); return changed 0; // 改變過(guò)系統(tǒng)調(diào)色板才返回TRUE } case WM_PALETTECHANGED: if ((HWND)wParam hwnd) break; // 自己引發(fā)的廣播忽略 { HDC hdc GetDC(hwnd); HPALETTE hOldPal SelectPalette(hdc, g_hPalette, FALSE); RealizePalette(hdc); SelectPalette(hdc, hOldPal, FALSE); ReleaseDC(hwnd, hdc); InvalidateRect(hwnd, NULL, TRUE); // 顏色已變必須重繪 } break;SelectPalette的第三個(gè)參數(shù)bForceBackground值得單獨(dú)解釋。傳 FALSE 表示窗口在前臺(tái)時(shí)才把調(diào)色板完整實(shí)現(xiàn)到系統(tǒng)調(diào)色板后臺(tái)時(shí)只用系統(tǒng)保留色傳 TRUE 則強(qiáng)制后臺(tái)窗口也參與調(diào)色板競(jìng)爭(zhēng)。MDI 子窗口全部設(shè) FALSE 就夠了設(shè) TRUE 會(huì)產(chǎn)生頻繁的全局調(diào)色板震蕩整個(gè)桌面可見(jiàn)地閃。4.3 調(diào)色板閃爍palette flash的原理與規(guī)避前后臺(tái)窗口交替觸發(fā)調(diào)色板閃爍是 256 色時(shí)代最著名也最玄學(xué)的視覺(jué)問(wèn)題?，F(xiàn)象是窗口切換時(shí)屏幕顏色先閃一下錯(cuò)誤的色調(diào)再恢復(fù)正常。原因可以拆成兩步后臺(tái)窗口 A 原來(lái) Realize 了 236 項(xiàng)顏色前臺(tái)窗口 B 切換到前臺(tái)后 Realize 了自己的調(diào)色板把系統(tǒng)調(diào)色板整體換血屏幕剛刷出的那一瞬間用的是 B 的調(diào)色板但畫(huà)面上還殘留著 A 窗口的像素。規(guī)避辦法有兩條一是盡量減少真正 Realize 的窗口數(shù)量后臺(tái)窗口不要響應(yīng)WM_PALETTECHANGED只有被覆蓋區(qū)域的窗口才需要重繪二是在框架窗口層級(jí)統(tǒng)一處理讓所有 MDI 子窗口共享一套調(diào)色板策略尤其是「兩張位圖共用同一個(gè)調(diào)色板」的情況完全不需要來(lái)回切換。源碼包如果做了調(diào)色板緩存性能會(huì)明顯好于每次繪制時(shí)重新選調(diào)色板的版本。4.4 在真彩顯示器上處理這包源碼調(diào)色板代碼到底還有沒(méi)有用現(xiàn)在的開(kāi)發(fā)機(jī)早就是 24 位或 32 位真彩256 色調(diào)色板看起來(lái)像古董。但真實(shí)的存量場(chǎng)景比想象中復(fù)雜遠(yuǎn)程桌面RDP 在低色深會(huì)話(huà)下、老式工控機(jī)的顯卡驅(qū)動(dòng)、嵌入式終端里8 位色模式依然存在。而且 Windows 有一個(gè)兼容機(jī)制即使當(dāng)前是真彩模式只要你的窗口 SelectPalette 了GDI 也會(huì)給窗口一個(gè)邏輯調(diào)色板映射雖然不會(huì)造成系統(tǒng)級(jí)顏色沖擊但窗口激活時(shí)仍然會(huì)產(chǎn)生輕微的閃爍。所以我的建議是調(diào)色板代碼不要?jiǎng)h而是加一層條件編譯或運(yùn)行時(shí)判斷。用GetDeviceCaps(hdc, BITSPIXEL)判斷當(dāng)前設(shè)備色深大于 8 位時(shí)跳過(guò)RealizePalette只保留SelectPalette的 DIB 繪制定位功能。這樣既保證低色深環(huán)境不出問(wèn)題又不拖累真彩環(huán)境下的性能和流暢度是很多商業(yè)源碼包里的通行做法。5. 避坑筆記調(diào)色板程序最常見(jiàn)的 5 個(gè)翻車(chē)現(xiàn)場(chǎng)5.1 現(xiàn)象位圖整體偏色紅色變藍(lán)、藍(lán)色變橙原因BMP 文件里像素分量按 BGR 順序存儲(chǔ)有些程序在讀取后「好心」做了 RGB 翻轉(zhuǎn)隨后 GDI 又按 BGR 解釋反向糾正了兩次。或者解析顏色表時(shí)把RGBQUAD的rgbBlue寫(xiě)到了rgbRed的位置。解決保持字節(jié)原樣別加任何額外轉(zhuǎn)換如果確實(shí)需要轉(zhuǎn)換渲染引擎用統(tǒng)一在讀取單色分量時(shí)按(r 16) | (g 8) | b處理。5.2 現(xiàn)象窗口從后臺(tái)切到前臺(tái)顏色整體錯(cuò)亂過(guò) 1 秒又恢復(fù)原因WM_PALETTECHANGED處理里漏了InvalidateRect。系統(tǒng)調(diào)色板被前臺(tái)窗口改變后舊窗口的像素還按舊調(diào)色板畫(huà)在屏幕上必須強(qiáng)制重繪讓 GDI 用新系統(tǒng)調(diào)色板重新映射一遍。解決在確認(rèn)不是自己引起的廣播后一定要重繪客戶(hù)區(qū)。缺失這一行是源碼重編譯后最常見(jiàn)的行為變化。5.3 現(xiàn)象位圖拉伸后邊緣出現(xiàn)鋸齒放大后一格一格很粗糙原因StretchDIBits默認(rèn)使用COLORONCOLOR拉伸模式像素被直接復(fù)制或丟棄沒(méi)有插值。解決調(diào)整 DC 的拉伸模式常見(jiàn)做法是SetStretchBltMode(hdc, HALFTONE)并調(diào)用SetBrushOrgEx校正偏移。注意HALFTONE模式在低色彩下比BLACKONWHITE慢如果目標(biāo)位圖是照片且真彩環(huán)境值得開(kāi)如果是圖標(biāo)素材COLORONCOLOR反而更銳利。5.4 現(xiàn)象MDI 子窗口最大化后位圖只顯示左上角一塊其余是空白原因繪制時(shí)目標(biāo)矩形寫(xiě)死了位圖原始尺寸沒(méi)有根據(jù)子窗口客戶(hù)區(qū)大小做縮放。MDI 子窗口最大化后客戶(hù)區(qū)比位圖大而你仍按原始尺寸繪制剩余區(qū)域自然不會(huì)重繪。解決每次WM_SIZE里記錄客戶(hù)區(qū)寬高WM_PAINT里計(jì)算縮放比例用StretchDIBits把目標(biāo)矩形撐滿(mǎn)客戶(hù)區(qū)同時(shí)保持寬高比防止位圖變形。5.5 現(xiàn)象調(diào)色板程序在真彩顯卡上顏色偏淡像蒙了一層白霧原因256 色位圖的調(diào)色板被彩色管理或顯卡驅(qū)動(dòng)做了 sRGB 映射常見(jiàn)于老游戲和舊照片。解決直接用 24 位 BMP 或 PNG 轉(zhuǎn)成 24 位 DIB 做顯示源僅把調(diào)色版作為低色深模式的降級(jí)方案。這也是我把bmp_in_mdiclient用于新項(xiàng)目時(shí)第一個(gè)改掉的地方顯示路徑優(yōu)先走 24 位低色深才走調(diào)色板路徑。6. 進(jìn)階把 bmp_in_mdiclient 改造成現(xiàn)代 GDI 程序時(shí)我會(huì)先做的 4 件事首先把文件讀取全部換成內(nèi)存映射或一次性ReadFile進(jìn)內(nèi)存不要再fread多次小段讀。BMP 文件不大一次讀入后用指針偏移訪問(wèn)結(jié)構(gòu)體速度提升明顯而且可以方便地做「打開(kāi)失敗不泄露句柄」的統(tǒng)一清理。其次顯示路徑從StretchDIBits換成兩級(jí)方案真彩環(huán)境下先CreateDIBSection做一次離屏繪制再BitBlt上屏避免窗口拖動(dòng)時(shí)頻繁重采樣產(chǎn)生撕裂低色深環(huán)境仍走StretchDIBits。第三件要做的是給程序補(bǔ)上 DPI 感知聲明。老 GDI 代碼在 1080p 125% 縮放下會(huì)自動(dòng)被系統(tǒng)拉伸位圖邊緣發(fā)虛調(diào)色板映射位置也跟著偏移。加一行SetProcessDPIAware或聲明 manifest再按GetDpiForWindow動(dòng)態(tài)計(jì)算縮放體驗(yàn)完全不同。第四件是把調(diào)色板數(shù)據(jù)從全局變量改成窗口實(shí)例數(shù)據(jù)讓每個(gè) MDI 子窗口持有自己的g_hPalette和g_pBits否則打開(kāi)第二張圖時(shí)第一張就壞了。驗(yàn)證這套改造是否成功我會(huì)準(zhǔn)備兩個(gè)基線一個(gè) 256 色 BMP 照片一個(gè) 24 位 BMP 截圖分別在一臺(tái) Windows 7 低色深虛擬機(jī)設(shè)成 256 色和一臺(tái)真彩 Win10 上打開(kāi)對(duì)比目標(biāo)矩形邊界、滾動(dòng)條位置、窗口切換后的顏色還原度。「顏色在切窗口后不閃」和「縮放后邊緣不糊」這兩條過(guò)了這包源碼就算吃透了。說(shuō)句實(shí)操里的老實(shí)話(huà)我第一次接這種項(xiàng)目時(shí)也懶得管調(diào)色板想著反正真彩屏結(jié)果現(xiàn)場(chǎng)演示時(shí)切了一下窗口整張工程圖花了幾秒客戶(hù)直接對(duì)方案打問(wèn)號(hào)。從那以后我再也不敢刪調(diào)色板邏輯而是把調(diào)色板與顯示解耦留了降級(jí)路徑。這也是我建議你拿到bmp_in_mdiclient后第一個(gè)能落地的習(xí)慣先看它怎么管理調(diào)色板再談怎么改界面。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取 BMP位圖在MDI客戶(hù)端中的顯示與調(diào)色板管理實(shí)戰(zhàn)
簡(jiǎn)介面向Windows平臺(tái)C開(kāi)發(fā)者的商業(yè)編程源碼包重點(diǎn)解決MDI多文檔界面中加載、解析與顯示位圖的問(wèn)題適合學(xué)習(xí)圖形設(shè)備接口底層機(jī)制的開(kāi)發(fā)者。示例工程展示了完整流程先解析文件頭和信息頭理解位圖結(jié)構(gòu)再按從下到上的掃描行處理像素?cái)?shù)據(jù)對(duì)八位及以下顏色深度自動(dòng)構(gòu)建調(diào)色板將索引值轉(zhuǎn)為RGB顏色最后通過(guò)設(shè)備無(wú)關(guān)位圖與設(shè)備上下文配合將圖像繪制到MDI客戶(hù)區(qū)。工程基于MFC文檔視圖架構(gòu)演示了主框架、文檔類(lèi)、視圖類(lèi)與MDI客戶(hù)區(qū)的協(xié)作關(guān)系。壓縮包共29個(gè)文件以頭文件、C源文件和資源腳本為主兼顧位圖圖標(biāo)素材與編譯產(chǎn)物EXE整體僅61KB結(jié)構(gòu)緊湊便于查閱代碼結(jié)構(gòu)清晰注釋風(fēng)格貼近商業(yè)項(xiàng)目。目前已有120人學(xué)習(xí)下載。通過(guò)分析源碼可加深對(duì)24位真彩與8位索引色位圖存儲(chǔ)差異的認(rèn)識(shí)掌握設(shè)備無(wú)關(guān)位圖創(chuàng)建、設(shè)備上下文選擇與顯示輸出的關(guān)鍵接口用法并學(xué)習(xí)窗口消息處理、顏色適配、內(nèi)存釋放等商業(yè)級(jí)編程技巧對(duì)構(gòu)建穩(wěn)定高效的桌面應(yīng)用具有實(shí)際參考價(jià)值也是深入理解Windows位圖格式的良好范例。1. 這個(gè)源碼包到底在解決什么問(wèn)題位圖、調(diào)色板與 MDI 客戶(hù)端的三方協(xié)作如果你是做過(guò) Win32 界面維護(hù)的老工程師看到bmp_in_mdiclient.zip這個(gè)文件名大概會(huì)立刻意識(shí)到這不是一個(gè)花哨的 demo而是 Windows 編程里一個(gè)長(zhǎng)期存在的經(jīng)典組合——把位圖裝進(jìn) MDI 客戶(hù)區(qū)同時(shí)正確處理調(diào)色板。它是“商業(yè)編程-源碼”這個(gè)序列里少有的、把 GDI 底層機(jī)制串起來(lái)的范例文件讀盤(pán)、DIB 解析、顏色表映射、MDI 子窗口注冊(cè)、繪制與消息循環(huán)。這套代碼適合誰(shuí)兩類(lèi)人。一類(lèi)是維護(hù)存量系統(tǒng)的開(kāi)發(fā)者手里還跑著 Windows 2000/XP 時(shí)代用 Visual C 或 Delphi 寫(xiě)的老 MFC/Win32 程序界面里嵌著大量 256 色位圖另一類(lèi)是剛接觸 Windows GDI 底層編程的學(xué)習(xí)者想搞清楚「為什么位圖在不同機(jī)器上顏色不一樣」「調(diào)色板到底管不管用」。本文會(huì)順著這個(gè)源碼包的核心思路把 BMP 文件結(jié)構(gòu)、MDI 客戶(hù)端顯示、調(diào)色板同步這三塊拆開(kāi)講最后給出一份能直接落地的改進(jìn)清單。2. 先看懂 BMP 文件里的顏色黑匣子文件頭、信息頭與調(diào)色板的讀取順序2.1 BMP 文件在磁盤(pán)上的實(shí)際布局為什么調(diào)色板位圖要單獨(dú)處理很多從 C# 或 Java 轉(zhuǎn)過(guò)來(lái)寫(xiě) Win32 的人第一次讀 BMP 文件時(shí)都會(huì)犯同一個(gè)錯(cuò)用fread一次性把整個(gè)文件讀進(jìn)緩沖區(qū)然后直接把緩沖區(qū)指針交給StretchDIBits。這在 24 位真彩位圖上常常能僥幸跑通因?yàn)檎娌?BMP 的信息頭后面直接就是像素?cái)?shù)據(jù)沒(méi)有顏色表但換成一個(gè) 8 位 BMP屏幕就會(huì)花成一片。原因是文件中間夾著一塊大小固定的顏色表你跳過(guò)了它像素?cái)?shù)據(jù)就整體偏移了。標(biāo)準(zhǔn)的 BMP 文件布局是三段式先是BITMAPFILEHEADER14 字節(jié)然后是BITMAPINFOHEADER40 字節(jié)起最后是實(shí)際數(shù)據(jù)區(qū)。數(shù)據(jù)區(qū)里是否包含顏色表取決于信息頭里的biBitCount。biBitCount為 8、4、1 時(shí)像素值只是調(diào)色板索引真正的顏色存在緊挨信息頭后面的 RGBQUAD 數(shù)組里為 16、24、32 時(shí)像素直接攜帶顏色分量沒(méi)有顏色表。這個(gè)字段是整個(gè)讀取邏輯的分岔點(diǎn)。// 讀取BMP文件并提取信息頭與調(diào)色板只讀關(guān)鍵結(jié)構(gòu) BITMAPFILEHEADER bf; BITMAPINFOHEADER bi; DWORD dataOffset; FILE* fp fopen(szPath, rb); if (!fp) return FALSE; fread(bf, sizeof(BITMAPFILEHEADER), 1, fp); fread(bi, sizeof(BITMAPINFOHEADER), 1, fp); dataOffset bf.bfOffBits; // 像素?cái)?shù)據(jù)的起始偏移通常在顏色表后 if (bi.biBitCount 8) { // 8位及以下位圖必須讀到顏色表否則后面的像素?zé)o法解碼 DWORD clrCount bi.biClrUsed ? bi.biClrUsed : (1 bi.biBitCount); RGBQUAD palette[256]; fread(palette, sizeof(RGBQUAD), clrCount, fp); // 這里可以把palette轉(zhuǎn)成LOGPALETTE供CreatePalette使用 } fclose(fp);這段代碼的關(guān)鍵在一個(gè)細(xì)節(jié)顏色表數(shù)量不是永遠(yuǎn)等于1 biBitCount。當(dāng)biClrUsed不為 0 時(shí)文件里只保存了實(shí)際用到的顏色項(xiàng)一般常見(jiàn)的情況是biClrUsed 0表示顏色表填滿(mǎn)了 256 項(xiàng)。你如果忽略biClrUsed在遇到優(yōu)化過(guò)的文件時(shí)要么讀多、要么讀少后面繪制時(shí) GDI 會(huì)以信息頭聲明的顏色數(shù)為準(zhǔn)兩邊對(duì)不上就會(huì)偏色或干脆畫(huà)不出東西。2.2 調(diào)色板位圖與真彩位圖的組織差異像素?cái)?shù)據(jù)里的索引到底是什么調(diào)色板位圖里存的是索引不是顏色。這句話(huà)值得反復(fù)強(qiáng)調(diào)。8 位 BMP 的每個(gè)像素占 1 個(gè)字節(jié)值域 0 到 255這個(gè)值對(duì)應(yīng)顏色表中第 N 個(gè) RGBQUAD 的顏色。4 位圖一個(gè)字節(jié)裝兩個(gè)像素高位是前一個(gè)像素的索引低位是后一個(gè)1 位圖一個(gè)字節(jié)裝 8 個(gè)像素每個(gè)像素只占 1 bit。處理低位圖時(shí)要按位拆開(kāi)再查顏色表否則會(huì)把兩個(gè)像素當(dāng)成一個(gè)去顯示。真彩位圖則完全繞開(kāi)調(diào)色板。24 位每像素 3 字節(jié)按 BGR 順序存儲(chǔ)32 位多一個(gè)保留字節(jié)常用于帶 alpha 通道的界面素材。這里有個(gè)老手都熟悉的反直覺(jué)點(diǎn)文件里是 BGR但 GDI 的RGBQUAD結(jié)構(gòu)體字段名是rgbBlue / rgbGreen / rgbRed所以直接讀出來(lái)就是對(duì)的反而是你自己去「糾正」字節(jié)序會(huì)出錯(cuò)。調(diào)色板在 MDI 程序里還有一個(gè)特殊地位它不是只服務(wù)于當(dāng)前窗口而是由系統(tǒng)統(tǒng)一管理。Windows 在 256 色模式下只有一個(gè)系統(tǒng)調(diào)色板所有窗口共享 20 個(gè)系統(tǒng)保留色剩下 236 個(gè)可由前臺(tái)窗口自由映射。這就是為什么同一個(gè)位圖在一個(gè)程序里顏色正常切到另一個(gè)程序再切回來(lái)就變色——不是文件壞了是調(diào)色板被搶占后沒(méi)恢復(fù)。2.3 低位圖在 MDI 場(chǎng)景里的顯示成本為什么不能直接用 BitBlt把調(diào)色板位圖加載成HBITMAP之后很多初學(xué)者會(huì)順手用BitBlt往窗口上貼。這在真彩模式下沒(méi)問(wèn)題在 256 色模式下會(huì)翻車(chē)因?yàn)槟阗N的是位圖索引而B(niǎo)itBlt默認(rèn)按系統(tǒng)調(diào)色板解釋顏色。正確的做法是用CreateDIBitmap把 DIB 轉(zhuǎn)成 DDB 并關(guān)聯(lián)位圖自身的調(diào)色板或者干脆保持 DIB 格式用StretchDIBits直接畫(huà)。從源碼包的名字bmp_in_mdiclient推斷它的核心路徑也走的是 DIB 方案解析出來(lái)的調(diào)色板交給CreatePalette像素?cái)?shù)據(jù)連同BITMAPINFO保留在內(nèi)存中繪制時(shí)用StretchDIBits一次完成調(diào)色板映射和伸縮。這個(gè)選擇比 DDB 方案更穩(wěn)因?yàn)?DDB 是設(shè)備相關(guān)的換機(jī)器、換顯卡、換色彩模式都可能失效而 DIB 是設(shè)備無(wú)關(guān)的同一份內(nèi)存數(shù)據(jù)在任何機(jī)器上都能按BITMAPINFO里的參數(shù)解釋。3. 在 MDI 客戶(hù)區(qū)顯示位圖從 LoadImage 到 StretchDIBits 的完整代碼路徑3.1 先搭好 MDI 的架子框架窗口、客戶(hù)端窗口與子窗口的關(guān)系MDI 程序的窗口層級(jí)是三層框架窗口Frame、MDI 客戶(hù)端窗口MDIClient、子窗口Child。bmp_in_mdiclient要做的是在子窗口的客戶(hù)區(qū)里顯示位圖而子窗口本身在 MDI 客戶(hù)區(qū)里可以被拖動(dòng)、最大化和層疊。這三者的消息傳遞順序決定了調(diào)色板通知會(huì)先到框架窗口再?gòu)腤M_MDINEXT等廣播消息擴(kuò)散到子窗口。創(chuàng)建 MDI 子窗口時(shí)框架窗口的WM_CREATE里必須調(diào)用DefFrameProc并注冊(cè)MDICLIENT窗口類(lèi)否則子窗口無(wú)法建立。常見(jiàn)的錯(cuò)誤是把 MDI 客戶(hù)端當(dāng)成普通子窗口處理結(jié)果CreateMDIWindow一直失敗。子窗口類(lèi)需要注冊(cè)自己的窗口過(guò)程WM_PAINT里拿到的hdc是子窗口的設(shè)備上下文繪制范圍是子窗口客戶(hù)區(qū)不是整個(gè)屏幕。// 注冊(cè)MDI子窗口類(lèi)簡(jiǎn)化版 WNDCLASS wc {0}; wc.lpfnWndProc ChildWndProc; wc.hbrBackground (HBRUSH)(COLOR_WINDOW 1); wc.lpszClassName BmpChildClass; RegisterClass(wc); HWND hClient GetParent(hwndFrame); // 框架窗口的客戶(hù)區(qū)是MDIClient CLIENTCREATESTRUCT ccs { hInst, 0 }; HWND hChild CreateMDIWindow( BmpChildClass, // 子窗口類(lèi)名 szFileName, // 標(biāo)題顯示文件名 WS_CHILD | WS_VISIBLE | WS_THICKFRAME, 10, 10, 640, 480, // 初始位置與尺寸 hClient, // 父窗口必須是MDIClient hInst );參數(shù)說(shuō)明CreateMDIWindow的父窗口必須是 MDIClient 句柄而不是框架窗口句柄這一點(diǎn)新手最容易搞反。WS_THICKFRAME給了子窗口可縮放邊框縮放后WM_SIZE會(huì)通知子窗口重算顯示區(qū)域如果你忘了在子窗口注冊(cè)類(lèi)時(shí)指定合適的背景畫(huà)刷縮放過(guò)程中會(huì)出現(xiàn)大量閃爍殘影。3.2 用 LoadImage 把位圖文件裝進(jìn)內(nèi)存參數(shù)與兩種數(shù)據(jù)源的取舍MDI 子窗口知道文件路徑后加載位圖有兩條路線。一條是用LoadImage加載成HBITMAP好處是代碼量少系統(tǒng)自動(dòng)解析文件類(lèi)型壞處是拿不到調(diào)色板數(shù)組不方便做 256 色下的精細(xì)調(diào)色板管理。另一條是手動(dòng)按第 2 章的解析流程讀取 DIB 數(shù)據(jù)雖然繁瑣但像素和調(diào)色板都在你手里繪制和顏色管理最靈活。源碼包若走「DIB 全線手動(dòng)」的路線那LoadImage可能只出現(xiàn)在菜單圖標(biāo)這類(lèi)附屬資源里主位圖推薦讀完文件頭后直接用SetDIBitsToDevice或StretchDIBits繪制。不過(guò)我還想提一個(gè)常見(jiàn)做法很多存量程序員圖省事先用LoadImage加載再用GetObject拿BITMAP結(jié)構(gòu)里的寬度高度繪制時(shí)發(fā)現(xiàn)沒(méi)有調(diào)色板信息最后還是回頭寫(xiě) DIB 解析。既然最終都要解析不如一步到位。// 用LoadImage加載位圖適用于加載ICO或臨時(shí)預(yù)覽 HBITMAP hBmp (HBITMAP)LoadImage( hInstance, szFullPath, IMAGE_BITMAP, 0, 0, // 寬高傳0表示按文件原始尺寸加載 LR_LOADFROMFILE // 必須加上否則默認(rèn)從exe資源中查找 );參數(shù)說(shuō)明LR_LOADFROMFILE是坑最多的一個(gè)標(biāo)志。不加它系統(tǒng)會(huì)去模塊的資源段里按szFullPath查找結(jié)果必然是返回 NULL。cx和cy為 0 時(shí)按文件原尺寸加載如果你指定了非零值LoadImage會(huì)做一次縮放但這個(gè)縮放質(zhì)量不如StretchDIBits可控放大的位圖會(huì)產(chǎn)生明顯的像素格點(diǎn)。3.3 StretchDIBits 繪制與縮放8 個(gè)關(guān)鍵參數(shù)一次說(shuō)清繪制是bmp_in_mdiclient的核心動(dòng)作。子窗口的WM_PAINT里拿到PAINTSTRUCT后用StretchDIBits把 DIB 畫(huà)到子窗口客戶(hù)區(qū)。這個(gè)函數(shù)有 11 個(gè)參數(shù)真正容易出錯(cuò)的只有 4 組目標(biāo)矩形x, y, cx, cy、源矩形xSrc, ySrc, cxSrc, cySrc、DIB 數(shù)據(jù)指針和顏色模式。源矩形寬高用BITMAPINFOHEADER里的biWidth和biHeight計(jì)算但要注意高度有正負(fù)之分。biHeight為正表示自底向上存儲(chǔ)讀文件后像素?cái)?shù)據(jù)要倒著掃為負(fù)才表示自頂向下。很多程序在掃描行序上翻車(chē)顯示出來(lái)的圖上下顛倒就是這個(gè)符號(hào)沒(méi)有處理。// 在MDI子窗口的WM_PAINT里繪制DIB case WM_PAINT: { PAINTSTRUCT ps; HDC hdc BeginPaint(hwnd, ps); if (g_pBits g_pBMI) { int destX 0, destY 0; int destW min(rect.right, g_bmpWidth); // 按客戶(hù)區(qū)比例截?cái)?int destH min(rect.bottom, g_bmpHeight); StretchDIBits( hdc, // 目標(biāo)設(shè)備上下文 destX, destY, destW, destH,// 目標(biāo)矩形客戶(hù)區(qū)左上角開(kāi)始 0, 0, g_pBMI-bmiHeader.biWidth, abs(g_pBMI-bmiHeader.biHeight), // 源矩形高度取絕對(duì)值 g_pBits, // 像素?cái)?shù)據(jù)指針 g_pBMI, // BITMAPINFO含調(diào)色板表 DIB_RGB_COLORS, // 顏色模式用邏輯調(diào)色板索引 SRCCOPY // 光柵操作碼直接拷貝 ); } EndPaint(hwnd, ps); break; }DIB_RGB_COLORS這個(gè)參數(shù)的語(yǔ)義要認(rèn)真理解它表示 DIB 數(shù)據(jù)里的顏色表是 RGB 值GDI 會(huì)自己完成匹配。如果你在低色彩模式下DIB_RGB_COLORS會(huì)結(jié)合系統(tǒng)調(diào)色板自動(dòng)映射如果 DIB 里帶著 LOGPALETTE你要用DIB_PAL_COLORS此時(shí) DIB 數(shù)據(jù)里的顏色表被解釋為 16 位索引數(shù)組指向當(dāng)前選入 DC 的邏輯調(diào)色板。兩者一旦混用輕則偏色重則整屏花掉。3.4 源碼剖析從打開(kāi)文件到子窗口重繪的調(diào)用鏈把這幾個(gè)環(huán)節(jié)串起來(lái)bmp_in_mdiclient的典型調(diào)用鏈?zhǔn)沁@樣的菜單項(xiàng)「打開(kāi)位圖」觸發(fā)GetOpenFileName彈文件對(duì)話(huà)框確認(rèn)后由框架窗口WM_COMMAND處理讀取路徑后創(chuàng)建新的 MDI 子窗口子窗口的WM_CREATE里完成 DIB 解析、調(diào)色板創(chuàng)建和像素?cái)?shù)據(jù)讀取最后觸發(fā)一次InvalidateRect讓W(xué)M_PAINT把圖畫(huà)出來(lái)。之后每次子窗口被遮擋再露出系統(tǒng)自動(dòng)補(bǔ)發(fā)WM_PAINT繪制邏輯不變。這個(gè)調(diào)用鏈里藏著一個(gè)決定成敗的細(xì)節(jié)DIB 解析最好放在WM_CREATE而不是WM_PAINT里做。因?yàn)閃M_PAINT在窗口重繪時(shí)會(huì)被頻繁觸發(fā)每次重新讀磁盤(pán)和解析顏色表程序會(huì)卡得沒(méi)法用。正確做法是解析一次把BITMAPINFO、像素指針和調(diào)色板句柄存成全局或窗口實(shí)例數(shù)據(jù)WM_PAINT只負(fù)責(zé)繪制。文件讀完后的清理也一樣重要。fread得到的緩沖區(qū)、CreatePalette創(chuàng)建的調(diào)色板句柄都要在WM_CLOSE或WM_DESTROY里釋放。調(diào)色板句柄不釋放程序每開(kāi)一張圖就泄漏 256 項(xiàng)系統(tǒng)資源開(kāi)幾十張圖之后系統(tǒng)調(diào)色板就會(huì)被耗干其他程序的顏色全部錯(cuò)亂這是 GDI 編程里最難排查的資源泄漏之一。4. 調(diào)色板管理SelectPalette 與 RealizePalette 的配合以及顏色閃爍的真相4.1 系統(tǒng)調(diào)色板在 256 色模式下是怎么運(yùn)作的236 個(gè)可用顏色的分配機(jī)制在 256 色顯示模式下Windows 系統(tǒng)維護(hù)一個(gè) 256 項(xiàng)的調(diào)色板。其中 10 項(xiàng)是系統(tǒng)保留色永遠(yuǎn)不變通常是黑色、白色、灰色系等基本色另外 10 項(xiàng)用于系統(tǒng)界面標(biāo)題欄、菜單等。真正可以給應(yīng)用用的有 236 項(xiàng)。前臺(tái)窗口可以通過(guò)RealizePalette把這 236 項(xiàng)全部映射成自己調(diào)色板里的顏色而所有后臺(tái)窗口只能部分映射映射不上的顏色由系統(tǒng)用最接近的顏色替代。這就是bmp_in_mdiclient為什么要單獨(dú)管理調(diào)色板的原因。顯示一張 256 色照片98% 的顏色都落在保留色之外如果你不把位圖的調(diào)色板 Realize 到系統(tǒng)調(diào)色板里整張圖會(huì)灰蒙蒙的顏色完全不對(duì)。源碼包里調(diào)色板相關(guān)代碼的占比往往比顯示代碼還大因?yàn)?MDI 多窗口環(huán)境下每個(gè)子窗口都想搶那 236 個(gè)顏色槽協(xié)調(diào)不好就互相頂?shù)簟?.2 三個(gè)關(guān)鍵消息的配合順序WM_PALETTECHANGED 與 WM_QUERYNEWPALETTE 的角色當(dāng)一個(gè) MDI 程序里有多個(gè)子窗口每個(gè)子窗口各顯示一張不同色調(diào)的位圖它們之間就產(chǎn)生了調(diào)色板競(jìng)爭(zhēng)。Windows 解決這個(gè)競(jìng)爭(zhēng)靠?jī)深?lèi)消息WM_QUERYNEWPALETTE發(fā)給即將獲得前臺(tái)焦點(diǎn)的窗口WM_PALETTECHANGED廣播給所有窗口通知它們系統(tǒng)調(diào)色板已經(jīng)被改變。這兩個(gè)消息都要處理缺一個(gè)就會(huì)花屏。重點(diǎn)說(shuō)順序。窗口從后臺(tái)切到前臺(tái)時(shí)系統(tǒng)先發(fā)WM_QUERYNEWPALETTE窗口在這里調(diào)用SelectPalette和RealizePalette如果確實(shí)改變了系統(tǒng)調(diào)色板返回 TRUE。隨后系統(tǒng)廣播WM_PALETTECHANGED給所有頂層窗口每個(gè)收到消息的窗口包括剛才那個(gè)前臺(tái)窗口都要判斷wParam是不是自己如果是自己就不用重復(fù)處理了。// 處理調(diào)色板消息前臺(tái)與后臺(tái)窗口的兩種響應(yīng) case WM_QUERYNEWPALETTE: { HDC hdc GetDC(hwnd); HPALETTE hOldPal SelectPalette(hdc, g_hPalette, FALSE); UINT changed RealizePalette(hdc); SelectPalette(hdc, hOldPal, FALSE); ReleaseDC(hwnd, hdc); return changed 0; // 改變過(guò)系統(tǒng)調(diào)色板才返回TRUE } case WM_PALETTECHANGED: if ((HWND)wParam hwnd) break; // 自己引發(fā)的廣播忽略 { HDC hdc GetDC(hwnd); HPALETTE hOldPal SelectPalette(hdc, g_hPalette, FALSE); RealizePalette(hdc); SelectPalette(hdc, hOldPal, FALSE); ReleaseDC(hwnd, hdc); InvalidateRect(hwnd, NULL, TRUE); // 顏色已變必須重繪 } break;SelectPalette的第三個(gè)參數(shù)bForceBackground值得單獨(dú)解釋。傳 FALSE 表示窗口在前臺(tái)時(shí)才把調(diào)色板完整實(shí)現(xiàn)到系統(tǒng)調(diào)色板后臺(tái)時(shí)只用系統(tǒng)保留色傳 TRUE 則強(qiáng)制后臺(tái)窗口也參與調(diào)色板競(jìng)爭(zhēng)。MDI 子窗口全部設(shè) FALSE 就夠了設(shè) TRUE 會(huì)產(chǎn)生頻繁的全局調(diào)色板震蕩整個(gè)桌面可見(jiàn)地閃。4.3 調(diào)色板閃爍palette flash的原理與規(guī)避前后臺(tái)窗口交替觸發(fā)調(diào)色板閃爍是 256 色時(shí)代最著名也最玄學(xué)的視覺(jué)問(wèn)題?，F(xiàn)象是窗口切換時(shí)屏幕顏色先閃一下錯(cuò)誤的色調(diào)再恢復(fù)正常。原因可以拆成兩步后臺(tái)窗口 A 原來(lái) Realize 了 236 項(xiàng)顏色前臺(tái)窗口 B 切換到前臺(tái)后 Realize 了自己的調(diào)色板把系統(tǒng)調(diào)色板整體換血屏幕剛刷出的那一瞬間用的是 B 的調(diào)色板但畫(huà)面上還殘留著 A 窗口的像素。規(guī)避辦法有兩條一是盡量減少真正 Realize 的窗口數(shù)量后臺(tái)窗口不要響應(yīng)WM_PALETTECHANGED只有被覆蓋區(qū)域的窗口才需要重繪二是在框架窗口層級(jí)統(tǒng)一處理讓所有 MDI 子窗口共享一套調(diào)色板策略尤其是「兩張位圖共用同一個(gè)調(diào)色板」的情況完全不需要來(lái)回切換。源碼包如果做了調(diào)色板緩存性能會(huì)明顯好于每次繪制時(shí)重新選調(diào)色板的版本。4.4 在真彩顯示器上處理這包源碼調(diào)色板代碼到底還有沒(méi)有用現(xiàn)在的開(kāi)發(fā)機(jī)早就是 24 位或 32 位真彩256 色調(diào)色板看起來(lái)像古董。但真實(shí)的存量場(chǎng)景比想象中復(fù)雜遠(yuǎn)程桌面RDP 在低色深會(huì)話(huà)下、老式工控機(jī)的顯卡驅(qū)動(dòng)、嵌入式終端里8 位色模式依然存在。而且 Windows 有一個(gè)兼容機(jī)制即使當(dāng)前是真彩模式只要你的窗口 SelectPalette 了GDI 也會(huì)給窗口一個(gè)邏輯調(diào)色板映射雖然不會(huì)造成系統(tǒng)級(jí)顏色沖擊但窗口激活時(shí)仍然會(huì)產(chǎn)生輕微的閃爍。所以我的建議是調(diào)色板代碼不要?jiǎng)h而是加一層條件編譯或運(yùn)行時(shí)判斷。用GetDeviceCaps(hdc, BITSPIXEL)判斷當(dāng)前設(shè)備色深大于 8 位時(shí)跳過(guò)RealizePalette只保留SelectPalette的 DIB 繪制定位功能。這樣既保證低色深環(huán)境不出問(wèn)題又不拖累真彩環(huán)境下的性能和流暢度是很多商業(yè)源碼包里的通行做法。5. 避坑筆記調(diào)色板程序最常見(jiàn)的 5 個(gè)翻車(chē)現(xiàn)場(chǎng)5.1 現(xiàn)象位圖整體偏色紅色變藍(lán)、藍(lán)色變橙原因BMP 文件里像素分量按 BGR 順序存儲(chǔ)有些程序在讀取后「好心」做了 RGB 翻轉(zhuǎn)隨后 GDI 又按 BGR 解釋反向糾正了兩次。或者解析顏色表時(shí)把RGBQUAD的rgbBlue寫(xiě)到了rgbRed的位置。解決保持字節(jié)原樣別加任何額外轉(zhuǎn)換如果確實(shí)需要轉(zhuǎn)換渲染引擎用統(tǒng)一在讀取單色分量時(shí)按(r 16) | (g 8) | b處理。5.2 現(xiàn)象窗口從后臺(tái)切到前臺(tái)顏色整體錯(cuò)亂過(guò) 1 秒又恢復(fù)原因WM_PALETTECHANGED處理里漏了InvalidateRect。系統(tǒng)調(diào)色板被前臺(tái)窗口改變后舊窗口的像素還按舊調(diào)色板畫(huà)在屏幕上必須強(qiáng)制重繪讓 GDI 用新系統(tǒng)調(diào)色板重新映射一遍。解決在確認(rèn)不是自己引起的廣播后一定要重繪客戶(hù)區(qū)。缺失這一行是源碼重編譯后最常見(jiàn)的行為變化。5.3 現(xiàn)象位圖拉伸后邊緣出現(xiàn)鋸齒放大后一格一格很粗糙原因StretchDIBits默認(rèn)使用COLORONCOLOR拉伸模式像素被直接復(fù)制或丟棄沒(méi)有插值。解決調(diào)整 DC 的拉伸模式常見(jiàn)做法是SetStretchBltMode(hdc, HALFTONE)并調(diào)用SetBrushOrgEx校正偏移。注意HALFTONE模式在低色彩下比BLACKONWHITE慢如果目標(biāo)位圖是照片且真彩環(huán)境值得開(kāi)如果是圖標(biāo)素材COLORONCOLOR反而更銳利。5.4 現(xiàn)象MDI 子窗口最大化后位圖只顯示左上角一塊其余是空白原因繪制時(shí)目標(biāo)矩形寫(xiě)死了位圖原始尺寸沒(méi)有根據(jù)子窗口客戶(hù)區(qū)大小做縮放。MDI 子窗口最大化后客戶(hù)區(qū)比位圖大而你仍按原始尺寸繪制剩余區(qū)域自然不會(huì)重繪。解決每次WM_SIZE里記錄客戶(hù)區(qū)寬高WM_PAINT里計(jì)算縮放比例用StretchDIBits把目標(biāo)矩形撐滿(mǎn)客戶(hù)區(qū)同時(shí)保持寬高比防止位圖變形。5.5 現(xiàn)象調(diào)色板程序在真彩顯卡上顏色偏淡像蒙了一層白霧原因256 色位圖的調(diào)色板被彩色管理或顯卡驅(qū)動(dòng)做了 sRGB 映射常見(jiàn)于老游戲和舊照片。解決直接用 24 位 BMP 或 PNG 轉(zhuǎn)成 24 位 DIB 做顯示源僅把調(diào)色版作為低色深模式的降級(jí)方案。這也是我把bmp_in_mdiclient用于新項(xiàng)目時(shí)第一個(gè)改掉的地方顯示路徑優(yōu)先走 24 位低色深才走調(diào)色板路徑。6. 進(jìn)階把 bmp_in_mdiclient 改造成現(xiàn)代 GDI 程序時(shí)我會(huì)先做的 4 件事首先把文件讀取全部換成內(nèi)存映射或一次性ReadFile進(jìn)內(nèi)存不要再fread多次小段讀。BMP 文件不大一次讀入后用指針偏移訪問(wèn)結(jié)構(gòu)體速度提升明顯而且可以方便地做「打開(kāi)失敗不泄露句柄」的統(tǒng)一清理。其次顯示路徑從StretchDIBits換成兩級(jí)方案真彩環(huán)境下先CreateDIBSection做一次離屏繪制再BitBlt上屏避免窗口拖動(dòng)時(shí)頻繁重采樣產(chǎn)生撕裂低色深環(huán)境仍走StretchDIBits。第三件要做的是給程序補(bǔ)上 DPI 感知聲明。老 GDI 代碼在 1080p 125% 縮放下會(huì)自動(dòng)被系統(tǒng)拉伸位圖邊緣發(fā)虛調(diào)色板映射位置也跟著偏移。加一行SetProcessDPIAware或聲明 manifest再按GetDpiForWindow動(dòng)態(tài)計(jì)算縮放體驗(yàn)完全不同。第四件是把調(diào)色板數(shù)據(jù)從全局變量改成窗口實(shí)例數(shù)據(jù)讓每個(gè) MDI 子窗口持有自己的g_hPalette和g_pBits否則打開(kāi)第二張圖時(shí)第一張就壞了。驗(yàn)證這套改造是否成功我會(huì)準(zhǔn)備兩個(gè)基線一個(gè) 256 色 BMP 照片一個(gè) 24 位 BMP 截圖分別在一臺(tái) Windows 7 低色深虛擬機(jī)設(shè)成 256 色和一臺(tái)真彩 Win10 上打開(kāi)對(duì)比目標(biāo)矩形邊界、滾動(dòng)條位置、窗口切換后的顏色還原度。「顏色在切窗口后不閃」和「縮放后邊緣不糊」這兩條過(guò)了這包源碼就算吃透了。說(shuō)句實(shí)操里的老實(shí)話(huà)我第一次接這種項(xiàng)目時(shí)也懶得管調(diào)色板想著反正真彩屏結(jié)果現(xiàn)場(chǎng)演示時(shí)切了一下窗口整張工程圖花了幾秒客戶(hù)直接對(duì)方案打問(wèn)號(hào)。從那以后我再也不敢刪調(diào)色板邏輯而是把調(diào)色板與顯示解耦留了降級(jí)路徑。這也是我建議你拿到bmp_in_mdiclient后第一個(gè)能落地的習(xí)慣先看它怎么管理調(diào)色板再談怎么改界面。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取