GDI实时抗锯齿源码：超采样与双缓冲VC++实现

简介：面向Windows GDI图形开发者的抗锯齿源码包，聚焦LineTo、Ellipse等绘图函数在斜线与曲线处产生的像素锯齿问题，适合具备VC++基础、希望提升界面绘制质量的中级开发者参考。压缩包共69个文件，约312KB，以gif、png图片素材和js、htm网页示例为主，辅以css样式、swf演示及zip源码与演示程序，既包含抗锯齿效果的网页版展示素材，也提供可编译的工程源码和演示程序。已有848人学习下载。代码围绕边缘检测、邻近像素颜色加权混合、多级采样展开，并兼顾实时性优化与不同分辨率、色深下的策略调整，读者可据此理解GDI抗锯齿的实现路径，对照演示观察边缘平滑效果，并将思路迁移到自绘控件、图表或图形编辑器等场景。

1. GDI 抗锯齿的真实短板：一份 VC++ 源码能补上什么

用 GDI 画一条 30 度斜线，放大镜底下一看，边缘是一排楼梯。这不是代码写错了，是 GDI 的LineTo、Polygon、StretchBlt本身不做像素覆盖率计算——要么整像素涂黑，要么整像素不涂。想在不引入 GDI+、Direct2D 的前提下把锯齿压下去，一个稳妥的路子就是超采样：先在放大 N 倍的离屏表面上画，再用HALFTONE模式缩回原尺寸，让边缘自然过渡出灰度。这份GDI 中实时消除图像锯齿源代码就是围绕这套思路写的 VC++ 工程，关键词里的 GDI、实时、消除图像锯齿、源代码、VC++、图像几个点它都占住了：一份能编译、能跑、能塞进既有绘图代码的参考实现。适合两类人——手里已有 GDI 绘制模块、不想大改架构就要出效果的中手；以及想搞明白"为什么我的界面缩放后糊成一团"的新手。

2. 源码结构拆解：从文件职责到一帧绘制的完整管线

拿到一个 VC++ 工程，先别急着点编译。把文件按职责分一遍，比逐行读代码效率高得多。这份源码包的目录基本是 Win32 桌面工程的标准骨架，按我拆过的同类项目经验，核心文件大致是这样几层：窗口与消息层、绘制表面层、抗锯齿合成层、资源与工程配置层。中间两层是真正值钱的部分，其余都是脚手架。

2.1 文件清单与各自负责的事

先把职责列清楚，后面读代码时心里有张地图。

工程配置里有两点必须先确认，不然编译期就得卡住：一是链接器附加依赖项里要有msimg32.lib，AlphaBlend声明在wingdi.h但实现在这个库里；二字符集设置要和源码里的TCHAR、_T()用法对齐，混用char与wchar_t字符串是新手最常见的第一次翻车点。

GdiSurface这一层值得单独说。它把"创建 DIB、拿到像素指针、创建兼容 DC、选入位图、用完还原"这一串动作包成一个对象，构造时分配、析构时释放。GDI 对象是内核句柄，泄漏不会立刻崩，但画上几千帧之后句柄耗尽，界面直接变黑。用 RAII 把SelectObject的旧句柄存起来、析构时还原，是最省心的写法。

2.2 一帧绘制的完整链路

WM_PAINT到达之后，源码做的事情可以按五步走：

1. BeginPaint拿到窗口 DC；
2. 检查离屏表面尺寸是否和客户区一致，不一致就重建；
3. 在放大 N 倍的采样 DC 上调用DrawScene，所有坐标乘以 N；
4. 用SetStretchBltMode(HALFTONE)把采样表面缩到后备表面；
5. BitBlt一次性贴到窗口 DC，EndPaint收尾。

为什么中间要夹一个"后备表面"而不是直接从采样表面贴到窗口？因为StretchBlt缩小是逐目标像素采样的，如果目标就是窗口 DC，缩放过程会在屏幕上逐行可见地刷出来，垂直同步不稳的时候整块画面会闪。多一层内存表面，等于把合成过程藏起来，屏幕上只看到最后那一次BitBlt。这就是双缓冲，老掉牙但一直有效。

链路里唯一容易忽略的是WM_ERASEBKGND。默认窗口过程会用背景刷填一遍，这一填和你的BitBlt之间就出现了一帧全背景色，闪烁的根源常在这里。源码里通常把该消息直接返回TRUE，表示"背景我自己处理"，让BitBlt覆盖全客户区。

2.3 为什么不走逐像素遍历

有人会问：直接把 DIB 像素读出来，对每条边算覆盖率不更精确？能，但代价不小。纯 CPU 遍历 1024×768 的 32 位图，每帧 78 万次像素访问，还要判断每个像素属于哪条边，实时性基本没戏。GDI+ 的SmoothingModeAntiAlias效果好，但意味着整套绘制接口要换，已有代码里成百上千个LineTo都得重写。超采样走的是另一条路：复用原有 GDI 绘制函数，只改坐标系和最后的缩放，代码侵入性最小，CPU 开销集中在那一次StretchBlt上，而且缩放算法由驱动和 GDI 内部优化，通常比手写的逐像素循环快。

代价是显存和内存占用随倍率平方增长。4 倍采样意味着 16 倍像素量，1080p 窗口就要一张 7680×4320 的 DIB，接近 130MB。所以倍率不能拍脑袋定，得看窗口尺寸和图形复杂度，下一章会给出具体取值参考。

3. 离屏表面与双缓冲：把绘制搬到 32 位 DIB 上

抗锯齿的效果上限，取决于你用什么样的表面来承载中间结果。用CreateCompatibleBitmap创建的是设备相关位图，像素格式跟着屏幕走，可能是 16 位色，Alpha 通道根本不存在；用CreateDIBSection创建 32 位 DIB，你能直接拿到像素指针，也能保证 Alpha 字节在。这份源码选的是后者，这是做边缘混合的前提。

3.1 创建 32 位 DIB 离屏表面

// 创建自上而下的 32 位 DIB，返回位图句柄，像素指针从 ppBits 带出 HBITMAP CreateOffscreenDIB(HDC hRefDC, int w, int h, void** ppBits) { BITMAPINFO bi = {0}; bi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); bi.bmiHeader.biWidth = w; bi.bmiHeader.biHeight = -h; // 负值 = 自上而下，行序与屏幕一致 bi.bmiHeader.biPlanes = 1; bi.bmiHeader.biBitCount = 32; // 只有 32 位才有 Alpha 字节 bi.bmiHeader.biCompression = BI_RGB; return CreateDIBSection(hRefDC, &bi, DIB_RGB_COLORS, ppBits, NULL, 0); }

biHeight取负值是关键。正高度表示自下而上存储，第 0 行在内存末尾，你按y * stride算偏移时整张图会上下颠倒，调试时看着像"图像翻转 bug"，其实是格式约定。负高度的写法在 Win32 里合法，且省掉一次手动翻转。biBitCount = 32加BI_RGB不需要调色板，GDI 会按0xAARRGGBB的小端序解析，内存里依次是 B、G、R、A 四个字节，这个顺序在后面做预乘时要用到，记反了颜色就全错。

ppBits返回的指针是 GDI 分配的，不需要你释放，但位图必须DeleteObject。指针在DeleteObject之后立即失效，别把裸指针存到对象里跨帧用——尺寸一变就得重建，旧指针指向的内存已经还给系统了。

3.2 双缓冲与绘制入口

void CMainWnd::OnPaint() { PAINTSTRUCT ps; HDC hdc = BeginPaint(m_hWnd, &ps); RECT rc; GetClientRect(m_hWnd, &rc); const int w = rc.right, h = rc.bottom; // 客户区尺寸变了就重建所有表面，避免拉伸失真 if (w != m_nWidth || h != m_nHeight) RecreateSurfaces(w, h); HDC hMemDC = CreateCompatibleDC(hdc); HGDIOBJ hOldBmp = SelectObject(hMemDC, m_hBackBmp); // 1) 在 N 倍大的采样表面上绘制场景 DrawScene(m_hSampleDC, m_nSampleRate); // 2) 降采样：采样表面 -> 后备表面 SetStretchBltMode(hMemDC, HALFTONE); SetBrushOrgEx(hMemDC, 0, 0, NULL); // 必须重置刷子原点 StretchBlt(hMemDC, 0, 0, w, h, m_hSampleDC, 0, 0, w * m_nSampleRate, h * m_nSampleRate, SRCCOPY); // 3) 一次性上屏，屏幕上不会看到中间过程 BitBlt(hdc, 0, 0, w, h, hMemDC, 0, 0, SRCCOPY); SelectObject(hMemDC, hOldBmp); DeleteDC(hMemDC); EndPaint(m_hWnd, &ps); } // 吞掉背景擦除，避免 BitBlt 之前闪一帧底色 BOOL CMainWnd::OnEraseBkgnd(HDC) { return TRUE; }

三个参数值得掰开看。SetStretchBltMode的HALFTONE是唯一会做像素平均的模式，COLORONCOLOR是直接丢弃多余行、BLACKONWHITE是按与运算合成，都会让缩小后的边缘重新变硬。SetBrushOrgEx那一行看着突兀，是因为HALFTONE内部靠一个 8×8 的抖动图案工作，如果刷子原点不是(0,0)，图案会整体偏移，表现为整张图有规律的网格纹或者轻微错位——这是这套代码最容易被漏掉的一行。

RecreateSurfaces里要做的事：删掉旧的采样位图、后备位图、两个内存 DC，按新尺寸和倍率重建，再重新SelectObject。频繁拖动窗口边框会触发大量重建，实际项目里我会在WM_ENTERSIZEMOVE时降倍率、WM_EXITSIZEMOVE时恢复，拖动过程用 1 倍采样保证跟手。

3.3 表面的生命周期

采样 DC 和后 DC 是两个独立的兼容 DC，各自选入自己的位图。它们不参与窗口绘制，只在OnPaint里被读。构造顺序上，必须先有窗口 DC 才能CreateCompatibleDC，所以初始化放在WM_CREATE之后、第一次WM_PAINT里惰性创建更稳，避免窗口还没拿到有效 DC 时创建失败返回NULL。

SelectObject返回的旧句柄一定不能丢。每个 DC 创建时默认选入一张 1×1 单色位图，你不还原就DeleteDC，那张默认位图会跟着泄漏——虽然只有一张，但配合每帧CreateCompatibleDC的写法，跑一天下来句柄表就满了。同理CreatePen、CreateSolidBrush用完必须DeleteObject，数量累积比位图快得多。

4. 实时抗锯齿核心：超采样、HALFTONE 缩放与边缘混合

整份源码的算法价值集中在这一层。思想一句话：把图形画在放大的坐标系里，每个显示像素对应 N×N 个子像素，缩放时把这些子像素平均，边缘自然得到 0 到 255 之间的灰度过渡。剩下的全是工程细节。

4.1 采样倍率怎么定

倍率不是越高越好，它和内存、CPU 是平方关系。

我一般把 4x 作为静态画面的默认值，2x 给需要跟随鼠标实时重绘的交互场景。判断依据很直接：窗口宽度乘倍率超过 8192 就往下调一档，很多集成显卡对超大位图的StretchBlt会退化到软件路径，帧率断崖式下跌。

4.2 在放大坐标系里画图

DrawScene是唯一需要改动的业务代码，规则只有一条：所有坐标乘倍率。

// rate 为采样倍率，绘制函数内部所有逻辑坐标统一放大 void DrawScene(HDC hdc, int rate) { // 1 像素宽的线在 4 倍采样下等于 0.25 个显示像素，边缘才会有过渡 HPEN hPen = CreatePen(PS_SOLID, 1, RGB(32, 32, 32)); HGDIOBJ hOldPen = SelectObject(hdc, hPen); MoveToEx(hdc, 10 * rate, 10 * rate, NULL); LineTo (hdc, 200 * rate, 120 * rate); // 圆角矩形同理，半径也要乘 HBRUSH hBrush = CreateSolidBrush(RGB(70, 140, 220)); HGDIOBJ hOldBrush = SelectObject(hdc, hBrush); Rectangle(hdc, 40 * rate, 160 * rate, 260 * rate, 320 * rate); SelectObject(hdc, hOldBrush); DeleteObject(hBrush); SelectObject(hdc, hOldPen); DeleteObject(hPen); }

线宽这里有个反直觉的点：在 4 倍表面上用PS_SOLID加 1 像素宽的笔，缩回原尺寸后线宽变成 0.25 显示像素，看起来会偏细偏淡。想要视觉上 1 像素的线，笔宽应该设成rate而不是1，这样缩放后正好是 1 个显示像素，同时边缘仍带亚像素过渡。源码里如果是按 1 像素画却嫌线条发虚，多半就是这里没对齐。

另一个坑是坐标取整。rate是整数时10 * rate没问题，如果哪天改成浮点缩放系数，MoveToEx收的是int，小数部分会被截断，多条线叠加后边缘反而更毛糙。需要浮点坐标时改Polyline或者在乘完之后统一MulDiv做四舍五入。

4.3 边缘 Alpha 混合

超采样解决的是几何边缘的灰度过渡，如果图像本身带透明通道（图标、贴图、叠加层），还得走AlphaBlend：

// 把带 Alpha 的源图叠到目标 DC，源位图必须是预乘 Alpha void BlendLayer(HDC hdcDst, int x, int y, int w, int h, HDC hdcSrc) { BLENDFUNCTION bf; bf.BlendOp = AC_SRC_OVER; bf.BlendFlags = 0; bf.SourceConstantAlpha = 255; // 整体不透明度，255 = 原样 bf.AlphaFormat = AC_SRC_ALPHA; // 使用源图逐像素 Alpha AlphaBlend(hdcDst, x, y, w, h, hdcSrc, 0, 0, w, h, bf); }

AC_SRC_ALPHA要求源位图是预乘的——RGB 三个通道在内存里已经乘过 Alpha。没做预乘直接喂进去，半透明区域会出现一圈发亮的白边，因为 GDI 把这部分 RGB 当成了不透明的颜色值又叠了一次 Alpha。修正方式是在填充像素时同步算一遍：

// 写入像素时顺手做预乘：R' = R * A / 255 inline void PutPixelPremul(BYTE* p, BYTE r, BYTE g, BYTE b, BYTE a) { p[0] = (BYTE)(b * a / 255); // DIB 内存序为 B G R A p[1] = (BYTE)(g * a / 255); p[2] = (BYTE)(r * a / 255); p[3] = a; // Alpha 字节保持原值 }

这一步是纯粹的查表级运算，在生成图标或纹理时一次性做完，运行时不再碰。如果源码包里没写预乘，先看它的透明图是不是全不透或全透明——这两种情况预乘与否结果一样，bug 会藏起来，等换成渐变透明才暴露。

4.4 组合起来的效果边界

超采样 +HALFTONE能压掉几何锯齿，但压不掉文字锯齿。TextOut在放大表面里渲染时，字体光栅化器按放大后的字号重新取字形，缩回去的笔画粗细可能和原尺寸不一致。文字这块的常见做法是单独走一层：文字直接画在最终尺寸的表面上，或者干脆用系统自带的 ClearType 渲染，别混进超采样管线。

还有一处是细线交叉点。两条 1 像素线在 4 倍表面交叉，交叉区域是 16 个子像素全黑，缩回去是一块深色小方块，视觉上比周围略重。倍率越高这块越不明显，2x 时还能看出来。如果图形里全是密集网格线，把倍率提到 4x，或者给线加一点点 Alpha 让重叠自然加深，都能缓解。

5. 避坑与排查：五条 GDI 抗锯齿的血泪经验

这套代码跑通不难，跑稳不容易。下面五条是我在同类实现里反复遇到过的，按"现象 → 原因 → 解决"写，照着对号入座。

一、缩小后整张图有细密网格纹或轻微错位

现象：本来纯色的区域出现规律的 8×8 抖动纹理，或者图像整体偏移一两个像素。原因：SetStretchBltMode设成HALFTONE之后没有调SetBrushOrgEx，GDI 内部的抖动图案从刷子当前原点开始铺，原点不在(0,0)时图案整体错位。解决：每次StretchBlt之前调一次SetBrushOrgEx(hdc, 0, 0, NULL)，注意这个设置是跟 DC 走的，DC 重建后要重新设。

二、窗口拖动或缩放时画面狂闪

现象：拖动边框时整块客户区在背景色和内容之间来回跳。原因：WM_ERASEBKGND被默认处理填了一遍背景，BitBlt又画一遍，两次之间被合成器采样到。解决：OnEraseBkgnd直接返回TRUE，并在WM_PAINT里保证BitBlt覆盖整个客户区，不留缝。

三、跑几分钟后界面变黑或绘制失败

现象：程序启动正常，运行一段时间后StretchBlt返回 0，画面不再更新。原因：GDI 对象泄漏。CreateCompatibleDC、CreatePen、CreateSolidBrush、CreateDIBSection每帧都建却没删，单进程句柄上限一万个，撑不了多久。解决：所有 GDI 对象用 RAII 包装，SelectObject存旧句柄并在析构时还原，DC 与位图保证成对释放。任务管理器里看 GDI 对象数，正常应该稳定在一个常数，持续上涨就是漏了。

四、高倍率下 CPU 单核打满

现象：4x 采样时鼠标移动都卡。原因：每帧重建 DIB 表面，或者每帧对全图做逐像素处理。CreateDIBSection会触发内存分配和清零，1080p、16 倍像素量下每帧几十毫秒起步。解决：表面只在尺寸或倍率变化时重建，平时复用；像素级处理放到图像加载阶段做一次，别放进绘制路径。

五、透明边缘出现黑边或白边

现象：贴上去的图标周围一圈深色或亮色描边。原因：预乘 Alpha 没做（白边），或者 DIB 初始化时背景是黑色而 Alpha 又被当成不透明（黑边）。解决：写入像素时同步预乘；没有 Alpha 的区域显式填空并把 Alpha 置 0；确认AlphaBlend的AlphaFormat是AC_SRC_ALPHA而不是 0。

6. 二次开发改造：把抗锯齿能力封装成可复用的绘制层

源码能跑之后，真正要花心思的是别让它散落在OnPaint里。我的做法是抽一个CAntiAliasCanvas类，把"倍率、表面、合成"三件事收进去，业务代码只跟一个Draw(HDC)回调打交道。

class CAntiAliasCanvas { public: // rate: 采样倍率；rate = 1 时退化为普通双缓冲 bool Create(HDC hRefDC, int w, int h, int rate = 4); void Resize(int w, int h); // 尺寸变化时调用，内部重建表面 void SetRate(int rate); // 拖窗口时降到 2，松手恢复 4 // 绘制回调：业务方在放大坐标系里画，坐标 = 逻辑坐标 * GetRate() typedef void (*DrawProc)(HDC hdc, int rate, void* pUser); void Render(HDC hdcTarget, DrawProc proc, void* pUser); ~CAntiAliasCanvas(); // 内部释放全部 GDI 对象 private: HDC m_hSampleDC = NULL, m_hBackDC = NULL; HBITMAP m_hSampleBmp = NULL, m_hBackBmp = NULL; HGDIOBJ m_hOldSample = NULL, m_hOldBack = NULL; int m_nWidth = 0, m_nHeight = 0, m_nRate = 4; };

Render内部就是第 3 章那三步，业务方只写DrawScene风格的回调函数，不用关心StretchBlt、刷子原点、双缓冲。改造成本主要在两处：一是把所有绘制入口的坐标乘rate，可以写个inline POINT S(int x, int y)辅助函数少打几个星号；二是把原来直接GetDC的地方换成从 canvas 拿 DC。

验证改造是否成功，我习惯用三个手段：

• 像素对比：同一图形分别用 1x 和 4x 渲染，导出两张 BMP 做差，边缘区域应该出现大量非零差值，中心纯色区域差值接近 0。如果全图都有差值，说明缩放路径有问题。
• 句柄计数：用GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)在渲染 1000 帧前后各取一次，数字必须一致。这是查泄漏最直接的办法，比肉眼盯画面靠谱。
• 耗时基线：QueryPerformanceCounter包住Render，1080p、4x、普通图形应在几毫秒量级。超过 16ms 就说明该降倍率了，别等用户抱怨卡。

还有一个我常加的开关：环境变量或注册表项控制默认倍率，线上出问题时不用重新编译就能一键退回 1x。抗锯齿这类"看起来更好但可能拖慢"的特性，一定要留后悔药。

从那以后我每次接 GDI 绘制相关的活，都会先在窗口里塞一个 1x/4x 的切换快捷键，一边拖窗口一边按——倍率、闪烁、句柄三件事在同一分钟内就能暴露出来。希望帮到你。

本文还有配套的精品资源，点击获取