简介面向Windows开发者的AlphaBlend半透明绘制示例工程由开发者u010918911整理并提供完整可编译运行的C项目适合有C基础、希望掌握图形界面半透明绘制的读者工程围绕Windows GDI中的Alpha混合技术展开演示如何借助32位位图Alpha通道将源图与目标设备上下文平滑混合并适用于游戏开发、GUI界面设计、图像处理软件等实际场景。压缩包内共15个文件约652KB包含C源文件与头文件、多张bmp位图素材、Visual Studio工程文件与资源脚本、已编译exe、README说明文档及license许可整体目录结构清晰代码量适中适合作为入门与进阶之间的练习。目前已有189人学习/下载代码详细展示了BLENDFUNCTION结构体字段、AC_SRC_OVER混合模式、sourceConstantAlpha与alphaFormat的含意以及AlphaBlend坐标参数的传参方式附带可执行程序便于边运行边观察半透明效果调整透明度参数能直观看到混合变化。对于希望在游戏界面或GUI设计中实现自然融合效果的开发者这份工程可省去环境配置与基础排错直接基于示例扩展自己的绘制逻辑。1. 把AlphaBlend用明白Windows上位图半透明绘制的关键API做桌面客户端时你需要让一个图标、浮层或者提示条以半透明方式叠在界面上这基本绕不开AlphaBlend。它是GDI里唯一一个不依赖GPU就能做批量像素混合的API把源位图的Alpha通道和目标DC逐像素混合再把结果写回目标。相比GDI的高层封装AlphaBlend更底层、更快也更容易控制全局半透明和逐像素半透明两种模式。本项目是一份可以直接编译的最小工程AlphaBlend_Test源码里包含一个完整的调用链适合做GUI自绘、图像处理工具以及还在维护Win32老项目的开发者。2. 先搞懂混合机制Alpha通道、BGRA布局与预乘黑边的由来2.1 从内存布局说起32位位图里那四个字节的排列Alpha混合的前提是源位图必须带Alpha通道在Windows上这意味着位图格式必须是32位DIBDevice Independent Bitmap。一个像素在内存里占4个字节但顺序可能和你直觉相反——它按B、G、R、A排列而不是R、G、B、A。typedef struct _PIXEL32 { BYTE b; // 蓝色分量 0-255 BYTE g; // 绿色分量 0-255 BYTE r; // 红色分量 0-255 BYTE a; // Alpha 透明度 0-255 } PIXEL32;0代表完全透明255代表完全不透明中间的数值决定混合比例。GDI内部处理位图扫描线时默认第一个字节是蓝色所以代码里读像素时要把b放到结构体最前面。从文件加载的普通BMP即使被读成32位Alpha通道也可能全是0这一点后面避坑章会展开。这个结构体不是必须用的你可以直接拿指针按字节偏移访问pPixels[y * width x]前面4个字节依次是b、g、r、a。排布顺序记不住没关系出黑边时第一个排查点就是它。2.2 BLENDFUNCTION结构体五个字段其实只动三个AlphaBlend的最后一个参数是BLENDFUNCTION绝大多数调用场景只需要设置三个字段BLENDFUNCTION bf {0}; bf.BlendOp AC_SRC_OVER; // 0x00标准源覆盖目标 bf.BlendFlags 0; // 保留字段必须为0 bf.SourceConstantAlpha 255; // 全局透明度0-255 bf.AlphaFormat AC_SRC_ALPHA; // 0x01启用源位图的逐像素AlphaBlendOp目前只接受AC_SRC_OVER表示源覆盖目标不存在目标覆盖源这种操作。SourceConstantAlpha是一个全局乘数给255就是不额外调整给128则是整体半透明。AlphaFormat填AC_SRC_ALPHA时每个像素的Alpha值和SourceConstantAlpha相乘得到最终透明度填0时源位图的Alpha通道被忽略只认全局值。这套参数组合要区分清楚想做整个图统一半透明就AlphaFormat 0想保留PNG里每个像素自己的透明度就AlphaFormat AC_SRC_ALPHA。两个都填是逐像素透明度再整体乘一遍最常见的应用是让一个带透明边缘的图标整体再变淡一些。2.3 预乘Alpha黑色边缘到底从哪来很多人第一次用AlphaBlend画出来的图边缘带一圈黑边或暗色光晕这是最经典的翻车现场。原因在于AlphaBlend内部按预乘AlphaPremultiplied Alpha计算而普通位图编辑器保存的是非预乘数据。预乘的概念是每个像素的RGB在存储前先乘以自己的Alpha值即R R * A / 255。混合时系统直接用预乘后的RGB做线性插值不再乘法。对非预乘数据正确的还原公式是R R * 255 / A。如果你的源位图直接来自PNG解码RGB保存的是原始颜色没做预乘那么边缘半透明区域的颜色值就会被AlphaBlend当作已经乘过Alpha的RGB去混合结果混出来偏黑。解决方式是在调用AlphaBlend之前对每个像素做一次预乘转换// 把非预乘的像素转成预乘格式 PIXEL32* p (PIXEL32*)pBits; for (int i 0; i width * height; i) { if (p[i].a 0) { p[i].r p[i].g p[i].b 0; // 全透明区域RGB清零防止污染目标背景 } else { p[i].r (BYTE)((p[i].r * p[i].a 127) / 255); p[i].g (BYTE)((p[i].g * p[i].a 127) / 255); p[i].b (BYTE)((p[i].b * p[i].a 127) / 255); } }这段代码里的127是四舍五入避免直接整除导致亮度损失。它在每个像素上做一次乘除性能损耗可以接受但如果位图很大而且每帧都做建议只在加载时做一次。全透明区域的RGB清零尤其重要否则AlphaBlend混合时残留下无用颜色最终结果会带着一圈灰边。核心逻辑GDI要求源数据是预乘的你的数据如果不是就必须在内存层面转成它要的样子这不是API选项能解决的。3. 搭建最小可运行工程从CreateDIBSection到第一帧半透明3.1 准备源位图为什么LoadBitmap和LoadImage都不靠谱不少新手第一步就踩坑用LoadBitmap加载一个32位BMP结果AlphaBlend后整个图全透明或者根本看不到。原因是LoadBitmap返回的是GDI兼容位图DDB格式通常是16位或24位没有Alpha通道。LoadImage加LR_CREATEDIBSECTION能得到32位DIB但BMP文件本身如果没有写入Alpha数据加载出来的Alpha通道全是0画出来依然是透明的。正确做法是直接创建DIB Section自己往内存里填像素或者从PNG解码出32位RGBA数据再拷贝进来。创建一个可用的32位源位图是这样写的BITMAPINFO bmi {0}; bmi.bmiHeader.biSize sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth 128; bmi.bmiHeader.biHeight -128; // 负数表示自上而下的扫描线 bmi.bmiHeader.biPlanes 1; bmi.bmiHeader.biBitCount 32; bmi.bmiHeader.biCompression BI_RGB; void* pBits NULL; HDC hdcScreen GetDC(NULL); HBITMAP hBitmap CreateDIBSection(hdcScreen, bmi, DIB_RGB_COLORS, pBits, NULL, 0); ReleaseDC(NULL, hdcScreen);biHeight填负数内存第一行对应图像最上面一行处理像素时不容易犯方向错误。biBitCount必须是32alpha通道才会被保留。pBits直接指向像素内存填完数据之后不要释放它归位图所有。从PNG解码时常见做法是先用GDI的Bitmap::LockBits拿到BGRA原始数据再memcpy到pBits。这一步要确保解码结果是预乘格式GDI默认不预乘所以拷贝前要过一遍上一节的预乘循环。3.2 屏幕上的第一帧半透明完整调用序列源位图准备好了再把位图选进一个内存DC然后调用AlphaBlend。完整流程如下// 在WM_PAINT里绘制 PAINTSTRUCT ps; HDC hdc BeginPaint(hwnd, ps); // 先画一个不透明的背景色再叠半透明图 HBRUSH hBrush CreateSolidBrush(RGB(120, 180, 220)); FillRect(hdc, ps.rcPaint, hBrush); DeleteObject(hBrush); // 源DC把DIB Section选进去 HDC hdcMem CreateCompatibleDC(hdc); HBITMAP hOldBmp (HBITMAP)SelectObject(hdcMem, hBitmap); BLENDFUNCTION bf {0}; bf.BlendOp AC_SRC_OVER; bf.BlendFlags 0; bf.SourceConstantAlpha 200; // 整体偏透明 bf.AlphaFormat AC_SRC_ALPHA; // 逐像素Alpha生效 AlphaBlend(hdc, 30, 30, 128, 128, // 目标位置(30,30)大小128x128 hdcMem, 0, 0, 128, 128, // 源左上角(0,0)大小128x128 bf); SelectObject(hdcMem, hOldBmp); DeleteDC(hdcMem); EndPaint(hwnd, ps);这段代码值得注意的细节有三个CreateCompatibleDC(hdc)必须在目标DC创建之后调用否则兼容性可能出问题。AlphaBlend的源和目标矩形尺寸可以不一致它内部会做缩放拉伸但拉伸质量一般放大后会有明显锯齿。BeginPaint/EndPaint之间的绘制会被系统缓存窗口在多次WM_PAINT之间不需要手动保存结果。3.3 链接Msimg32.lib老工程最容易漏的一步AlphaBlend不在标准的Gdi32里它由Msimg32.dll导出。新建工程时如果直接调用AlphaBlend而没链接Msimg32.lib编译会报一个 unresolved external symbol错误。VS2013的项目可以在配置里加依赖项也可以直接在源代码里按动态方式加载typedef BOOL (WINAPI *fnAlphaBlend)(HDC, int, int, int, int, HDC, int, int, int, int, BLENDFUNCTION); fnAlphaBlend pAlphaBlend NULL; HMODULE hMsimg32 LoadLibraryA(Msimg32.dll); if (hMsimg32) { pAlphaBlend (fnAlphaBlend)GetProcAddress(hMsimg32, AlphaBlend); }动态加载的好处是程序在Win98/2000上也不会启动失败最多是混合功能不可用。要注意函数指针的调用约定是WINAPI写少了在32位下会栈不平衡。工程里如果用静态链接直接在源文件前加#pragma comment(lib, Msimg32.lib)最省事。4. 避坑实录AlphaBlend常见的五个翻车点与排查清单4.1 现象图像边缘有一圈黑色光晕放大或旋转带圆角、阴影的图标时边缘发黑看起来像脏脏的轮廓线。原因源位图的RGB没有预乘半透明区域的原始颜色值在做混合时被错误地当作预乘值参与计算导致混合结果比实际预期暗。核心是AlphaBlend内部按预乘处理这一点。解决在加载位图时遍历全部像素做预乘转换尤其把Alpha为0的像素RGB强制清零。转换后重画光晕消失。4.2 现象整个图完全看不见只留下一块背景色调用AlphaBlend后什么都没画出来或者画出来一个纯黑色矩形。原因常见的有三种。一是位图不是32位格式没有Alpha通道系统把每个像素的Alpha当成0于是完全透明二是AlphaFormat填了AC_SRC_ALPHA但源位图Alpha通道数据为空三是SourceConstantAlpha被误设成0。其中前两个占绝大多数。解决先用GetObject读回位图的biBitCount确认是32位再用下面这个函数检查像素Alpha是否有非零值// 检查DIB Section的Alpha通道是否有内容 int CheckAlphaChannel(HBITMAP hBmp, int width, int height) { DIBSECTION ds {0}; GetObject(hBmp, sizeof(ds), ds); BYTE* p (BYTE*)ds.dsBm.bmBits; int nonZeroCount 0; for (int i 3; i width * height * 4; i 4) { if (p[i] 0) nonZeroCount; } return nonZeroCount; }DS_BM.bmBits返回的是像素内存指针按每像素4字节递增取每4字节的第4个字节就是Alpha值。如果返回值是0说明源图根本没有透明度需要重新准备数据而不是继续调参数。4.3 现象缩放之后图像发虚、边缘布满杂色锯齿把一个小图标用AlphaBlend放大绘制到窗口背景上边缘出现颗粒状过渡黑色杂点明显。原因AlphaBlend的拉伸本质是点采样不做高质量双线性滤波边缘半透明像素在放大后被插值成不正确的混合值视觉上就是杂色。解决尽量不做运行时大比例缩放在加载阶段就把位图预缩放到需要尺寸把缩放次数控制在一次如果必须动态缩放可以用GDI的DrawImage配合高质量插值模式但那是另一套API混用时要保持DC状态统一。你还可以限制窗口最小尺寸避免用户把窗口拖到极小导致拉伸倍数过大。4.4 现象多层半透明叠加后背景越来越脏越叠越黑界面上有多个半透明层叠在一起例如一个半透明提示框浮在半透明地图上叠加区域颜色逐渐加深像蒙了一层灰。原因半透明混合不可交换必须先画不透明底层再按从远到近的顺序画半透明层。如果先画了一个半透明层又在其上叠另一个半透明层两个层的RGB会在混合中互相吞噬背景色参与计算的次数太多。解决调整绘制顺序保证每次AlphaBlend的目标DC里画的是已经定稿的背景多个半透明层需要叠加时先在一个临时内存DC里按顺序绘制最后一次性AlphaBlend到窗口。临时DC用32位格式创建避免中间过程丢失精度。4.5 现象拖动窗口或快速刷新时闪烁半透明区域撕裂窗口上有大块半透明区域拖动过程中边缘闪动图像像被扯开一样。原因WM_PAINT里直接往屏幕DC绘制每次重绘整片区域都重新混合又没做双缓冲导致系统先擦背景再画前景之间出现空窗。解决用双缓冲。先把所有内容画到一个内存DC最后用BitBlt整个提交到窗口避免背景擦除和前景绘制之间的时间差。只对变化的脏矩形做InvalidateRect不要全窗口无效化。5. 让透明度动起来淡入淡出循环与AlphaBitmap封装5.1 sourceConstantAlpha逐帧变化淡入淡出的正确写法实现渐显渐隐的常见错误是把Sleep放在主线程里阻塞窗口消息循环。正确做法是用定时器或帧时间戳驱动重绘。这里以SetTimer为例// 在窗口创建时启动定时器每16毫秒触发一次 SetTimer(hwnd, IDT_FADE, 16, NULL); // 全局变量维护当前透明度 int g_alpha 0; // 从0开始淡入 int g_dir 4; // 每帧增加4 case WM_TIMER: { if (wParam IDT_FADE) { g_alpha g_dir; if (g_alpha 255) { g_alpha 255; g_dir -4; } if (g_alpha 0) { g_alpha 0; g_dir 4; } InvalidateRect(hwnd, NULL, FALSE); // 触发重绘不清除背景 } break; } case WM_PAINT: { // 绘制时代码里把SourceConstantAlpha g_alpha }定时器间隔16ms对应约60帧这里不追求平滑到极致够用。InvalidateRect最后一个参数传FALSE不要清背景否则淡入过程中会看到底色闪烁。全局透明度叠加逐像素Alpha后最终效果是PNG本身的透明度基础上再整体乘一个系数。5.2 封装一个AlphaBitmap类后续直接复用把创建、预乘、绘制装进一个类里后面做多个控件、多张图时不用重复踩坑class AlphaBitmap { public: HBITMAP hBitmap; int width, height; bool Create(int w, int h) { width w; height h; BITMAPINFO bmi {0}; bmi.bmiHeader.biSize sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth w; bmi.bmiHeader.biHeight -h; bmi.bmiHeader.biPlanes 1; bmi.bmiHeader.biBitCount 32; bmi.bmiHeader.biCompression BI_RGB; HDC hdc GetDC(NULL); hBitmap CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, pixels, NULL, 0); ReleaseDC(NULL, hdc); return hBitmap ! NULL; } void Premultiply() { PIXEL32* p (PIXEL32*)pixels; for (int i 0; i width * height; i) { if (p[i].a 0) p[i].r p[i].g p[i].b 0; else { p[i].r (BYTE)((p[i].r * p[i].a 127) / 255); p[i].g (BYTE)((p[i].g * p[i].a 127) / 255); p[i].b (BYTE)((p[i].b * p[i].a 127) / 255); } } } void Draw(HDC hdc, int x, int y, BYTE globalAlpha) { HDC hdcMem CreateCompatibleDC(hdc); HBITMAP hOld (HBITMAP)SelectObject(hdcMem, hBitmap); BLENDFUNCTION bf {AC_SRC_OVER, 0, globalAlpha, AC_SRC_ALPHA}; AlphaBlend(hdc, x, y, width, height, hdcMem, 0, 0, width, height, bf); SelectObject(hdcMem, hOld); DeleteDC(hdcMem); } void Cleanup() { if (hBitmap) DeleteObject(hBitmap); } private: void* pixels; };这个类把整条调用链收口了实例化后只需三行Create、Premultiply、Draw。要注意Premultiply是幂等的重复调用不会出问题但没必要。如果你想更新某个像素更新后要重新做预乘不然新像素的颜色又变成非预乘状态。5.3 验证写法把混合结果读回来确认不是看上去对半透明效果用肉眼判断往往不准尤其是颜色偏差在10以内人眼根本分辨不出。严谨做法是把混合后的结果拷到另一个DIB里按坐标读像素算期望值。// 假设背景色是 RGB(120, 180, 220), 源图某像素是 RGB(200, 50, 50), alpha128 // 期望混合结果 // R (200 * 128 120 * (255 - 128)) / 255 160 // G (50 * 128 180 * (255 - 128)) / 255 123 // B (50 * 128 220 * (255 - 128)) / 255 146 // 用BitBlt把窗口内容拷到32位DIB再比较对应像素坐标的值误差在1以内视为正确。判断标准是混合公式结果 (源色 * 源Alpha 目标色 * (255 - 源Alpha)) / 255前提是源色已经预乘。写一个断言函数跑一遍比肉眼看十遍管用后面第6章还会把这个思路再往前推一步。6. 一个压箱底的验证技巧把混合结果按像素读回来校准透明度调试半透明效果最头疼的是看不清对不对。颜色差一点、透明度差百分之几靠肉眼根本发现不了。我后来养成了一个习惯凡是涉及AlphaBlend的逻辑改动都会强制跑一遍像素回读把混合结果和公式算出来的期望值做对比。具体操作是先在纯黑背景和纯白背景上各画一次目标图分别读回同一坐标的像素值。设源图那个像素的预乘颜色是C透明度是A黑背景混合结果B、白背景混合结果为W那么A 255 - (W - B) * 255 / (255 - 0); // 精确算出实际生效的Alpha R (B * 255 - A * 0) / (255 - A); // 还原源图实际参与混合的颜色预乘后如果还原出来的A值和SourceConstantAlpha乘以像素alpha后的预期不一致偏差超过2就说明预乘处理或DC设置里有问题。这套方法曾在一次项目里帮我抓到一个非常隐蔽的bug某个位图加载路径漏了预乘透明边缘在浅色背景下看着正常一换深色背景就发灰。用黑白背景双采样一秒定位到是Alpha通道被当成直通值使用。从那以后我每次写半透明相关代码都强制走一遍回读验证的流程宁可多写十几行校验代码也不愿意在一个看不清的显示效果上反复试探。这个小技巧希望帮到你。本文还有配套的精品资源点击获取