简介这份资源聚焦 Windows GDI 绘图中的锯齿问题面向使用 VC 进行图形界面开发、希望提升渲染质量的初中级开发者。它围绕 LineTo()、Ellipse() 等函数在绘制曲线和斜线时出现的像素阶梯现象给出了可实时运行的抗锯齿实现思路涉及边缘像素识别、邻域颜色加权混合、多级采样以及基于 SIMD 的并行加速与预计算缓存等性能优化手段并可能包含按分辨率与颜色深度动态调整策略的机制。压缩包为 rar 格式共 69 个文件约 312KB以 gif、png 图片和 js 脚本、htm 页面为主辅以 css 样式与少量 jpg、swf、zip 文件其中 zip 为工程源码与演示程序网页与图片素材用于呈现抗锯齿前后的对比效果。已有 848 人学习下载读者可据此理解 GDI 抗锯齿的算法流程与工程落地方式并将相关代码迁移到自己的绘图模块中参考复用。1. GDI 画出来的斜线全是台阶这份源代码要解决的就是这个老毛病前段时间接手一个 VC 写的工控界面客户抱怨屏幕上那条折线图「像楼梯」。翻代码一看全是老的 GDIMoveToEx/LineTo一把梭连SetStretchBltMode都没设过斜线和圆弧的锯齿在 1080P 屏上被放得一清二楚。后来换个思路不改绘制逻辑只在渲染管线的末端加一层 GDI 抗锯齿处理问题就压下去了。这套实时消除图像锯齿的 VC 源代码做的正是这件事——它把超采样、边缘像素 Alpha 混合、双缓冲和脏矩形刷新这几块拼成一个可复用的渲染骨架运行起来能实时看到斜线、圆、位图缩放的边缘被磨平帧率还能压在 60FPS 附近。目标读者很明确手上有一堆现成 GDI 绘制代码、不方便整体迁到 GDI 或 Direct2D但又得让画面看得过去的桌面端开发者。2. 工程骨架Win32 GDI 的双缓冲渲染结构这套代码没有用 MFC是纯 Win32 的窗口过程 一个自封装的画布类好处是能直接拖进任何 VC 工程里当静态库用不牵扯消息映射宏那一套。先看目录再看构建配置最后说清楚为什么在 GDI 已经存在的前提下还要绕回来写原生 GDI。2.1 目录结构与各文件职责源代码工程的目录组织如下按「基础设施 → 渲染后端 → 业务壳」三层划分AntiAliasGDI/ ├─ AntiAliasGDI.sln 解决方案VS2015 及以上可直接打开 ├─ src/ │ ├─ main.cpp WinMain 入口注册窗口类、消息循环 │ ├─ Canvas.h / Canvas.cpp 画布类持有前台/后台两套 DIB 与 DC │ ├─ Renderer.h 渲染后端抽象接口 │ ├─ RendererSSAA.cpp 超采样后端实现 │ ├─ RendererEdge.cpp 边缘混合后端实现 │ ├─ DibSection.h / .cpp 32 位 DIB Section 的 RAII 封装 │ ├─ Scene.cpp 示例场景斜线族、圆、位图缩放 │ └─ QpcTimer.h 基于 QueryPerformanceCounter 的计时器 ├─ res/ │ └─ app.rc 图标与版本资源 └─ test/ └─ pattern_gen.cpp 生成测试图案用于效果对比Canvas是核心它是一个「离屏优先」的类所有绘制先落到后台 DIB再一次性BitBlt到窗口 DC。Renderer.h只定义三个虚函数——Resize、BeginDraw、EndDraw这样两种抗锯齿算法可以互换也方便后续自己加第三种。2.2 为什么是原生 GDI 而不是 GDI很多人第一反应是「上 GDI 不就行了SmoothingModeAntiAlias一行搞定」。实际落地时会撞上三个问题一是 GDI 的Graphics对象和现有 HDC 混用时状态切换开销不小尤其是每帧重建Graphics的场景二是 GDI 在老机器上的GdiplusStartup/Shutdown生命周期管理容易出岔子DLL 里被反复初始化是常见翻车点三是部分老项目要链接进不允许额外依赖的宿主进程gdiplus.lib属于额外负担。原生 GDI 的抗锯齿靠两条路自己实现超采样把画面放大画再缩小和边缘后处理扫像素做混合。这两种做法的共同点是——不动原来的绘制代码只在末端加一道工序对已有工程侵入性最小。选型上更接近「外科手术」而不是「整体搬家」。2.3 编译环境与工程配置要点工程属性里有几处必须手动确认否则编译能过但跑起来效果不对配置项值原因字符集Unicode代码里用的是CreateWindowExW系列运行库多线程 (/MT) 或 DLL (/MD) 均可无第三方依赖两种都行附加依赖项msimg32.lib用到AlphaBlend做半透明叠加平台Win32 与 x64 都要能编指针截断在 x64 下会直接崩优化Release 下开 /O2逐像素处理对优化等级敏感提示AlphaBlend声明在wingdi.h但实现体在msimg32.lib忘了加这条依赖会报 LNK2019报错信息不会告诉你缺哪个库只能靠记。窗口创建部分没什么花活WS_OVERLAPPEDWINDOW加一个WM_TIMER或者自建渲染循环都行。示例里用的是WM_PAINT驱动配合InvalidateRect做局部刷新。3. 抗锯齿核心超采样与边缘混合的两条实现路线两种算法的适用场景不同超采样对几何图形线、圆、多边形效果好代价是显存和填充率边缘混合对已经画好的位图做后处理开销小但只对「边缘像素」有效。源代码里两条都给了可以按内容类型切换。3.1 超采样路线放大 N 倍画再缩回来原理一句话以 4 倍分辨率渲染再用双线性/半色调缩回原尺寸一个原像素由 16 个子像素平均得到边缘自然产生中间灰阶。关键是缩小时的StretchBlt模式必须设成HALFTONE否则 GDI 会走最近邻等于白干。// RendererSSAA.cpp —— 以 nFactor 倍尺寸离屏渲染后缩回 bool CRendererSSAA::EndDraw(HDC hdcTarget, const RECT rcDst) { // m_hdcBig / m_hBmpBig 在 Resize 时按 rcDst 的 nFactor 倍创建 // 此时 m_hdcBig 上已经用普通 GDI 调用画完了整幅内容 int nOldMode SetStretchBltMode(hdcTarget, HALFTONE); // HALFTONE 依赖刷子原点必须显式归零否则平铺错位 SetBrushOrgEx(hdcTarget, 0, 0, nullptr); BOOL bOk StretchBlt( hdcTarget, rcDst.left, rcDst.top, rcDst.right - rcDst.left, rcDst.bottom - rcDst.top, m_hdcBig, 0, 0, m_nBigW, m_nBigH, SRCCOPY); SetStretchBltMode(hdcTarget, nOldMode); // 恢复别污染调用方状态 return bOk ! FALSE; }逻辑说明m_hdcBig是 4 倍尺寸的 32 位 DIB 内存 DCm_nBigW/m_nBigH是对应的大图宽高。StretchBlt从大图取全幅、往目标 DC 的小矩形里塞缩放比例正好 1/4。HALFTONE模式下 GDI 内部会做加权平均边缘像素得到介于前景色和背景色之间的中间值。参数说明nFactor一般取 2 或 4。取 2 时性能损失约 4 倍填充率效果已经能看取 4 时边缘非常干净但 1920×1080 的画布需要 7680×4320 的离屏位图约 126MB 显存老显卡上会明显掉帧。经验值是——静态画面 4 倍、动态画面 2 倍或者干脆对动态层不做超采样只对静态背景做。3.2 边缘混合路线扫一遍像素只改边缘超采样贵在「全画布都按高分辨率重画」而边缘混合的思路相反正常分辨率画完然后逐像素判断它是不是处在颜色突变的位置如果是就把它和邻域像素做加权平均。// RendererEdge.cpp —— 3x3 邻域边缘检测 Alpha 混合 void CRendererEdge::BlurEdges(uint32_t* pBits, int nW, int nH, int nThreshold) { // 需要一个临时缓冲避免边算边改污染后续像素 std::vectoruint32_t vTmp(pBits, pBits nW * nH); for (int y 1; y nH - 1; y) { for (int x 1; x nW - 1; x) { uint32_t c vTmp[y * nW x]; uint32_t l vTmp[y * nW x - 1]; uint32_t r vTmp[y * nW x 1]; uint32_t u vTmp[(y - 1) * nW x]; uint32_t d vTmp[(y 1) * nW x]; // 用亮度差近似梯度够用且省一次开方 int nDiff std::abs(Luma(c) - Luma(l)) std::abs(Luma(c) - Luma(r)) std::abs(Luma(c) - Luma(u)) std::abs(Luma(c) - Luma(d)); if (nDiff nThreshold) { // 处在边缘中心像素权重 4四邻各 1总权重 8 pBits[y * nW x] Blend4(c, l, r, u, d, 4, 1); } } } }逻辑说明Luma是(r*77 g*150 b*29) 8的定点亮度公式避免浮点。Blend4按给定权重把五个像素的 BGR 分量分别加权求和再除总权重。只处理边缘像素非边缘区域原样保留所以整体不会糊。参数说明nThreshold是敏感度阈值典型取值 2448。调太小会把渐变背景也当成边缘画面发灰调太大则只剩最锐利的轮廓被处理锯齿仍有残留。Blend4的权重比是经验值想让边缘更柔和可以把中心权重从 4 降到 2。注意这个函数只对 32bpp 的 DIB 有效1/4/8/24 位图必须先转成 32 位。转换本身也有开销别在每帧里反复转。3.3 半透明叠加AlphaBlend 的正确打开方式有些场景不需要全画面抗锯齿只要把一个带 Alpha 通道的图形比如半透明提示框叠上去。GDI 原生支持靠AlphaBlend但它有几个不太好伺候的前提// 32bpp 源位图带 Alpha 通道时必须用 AC_SRC_ALPHA BLENDFUNCTION bf { AC_SRC_OVER, 0, 255, AC_SRC_ALPHA }; AlphaBlend(hdcDst, x, y, nW, nH, hdcSrc, 0, 0, nW, nH, bf);逻辑说明SourceConstantAlpha设为 255 表示不做整体透明度衰减透明度全部来自源像素自带的 Alpha 字节。这里有个血泪经验——如果源 DIB 的 Alpha 通道全是 0有些绘图 API 不会主动填AlphaBlend会画出一片空白看上去像函数失效实际是数据没准备好。参数说明第二个参数BlendOp只能是AC_SRC_OVER第四个参数必须同时给AC_SRC_ALPHA否则 GDI 会忽略像素自身的 Alpha只认SourceConstantAlpha。4. 实时性保障双缓冲、脏矩形与耗时控制抗锯齿本质上是拿算力换画面质量一旦处理不好「实时」两个字就没了。这部分是这套代码里最值得抄的部分——它决定了 4 倍超采样能不能稳定跑在 60FPS。4.1 双缓冲消灭闪烁的基础设施任何实时绘制都绕不开双缓冲。没有它超采样放大再缩小的过程中屏幕会先看到大图的一角再看到成品视觉上是「闪白」。画布类的做法是持有一张和客户区同尺寸的 32 位 DIB 作为「后备缓冲」所有绘制全在其中完成最后一次性搬运void CCanvas::Present(HDC hdcWindow, const RECT rcDirty) { // m_hdcBack 与 m_hBmpBack 在 Resize 时创建尺寸等于客户区 BitBlt(hdcWindow, rcDirty.left, rcDirty.top, rcDirty.right - rcDirty.left, rcDirty.bottom - rcDirty.top, m_hdcBack, rcDirty.left, rcDirty.top, SRCCOPY); }逻辑说明rcDirty是本次需要刷新的区域只搬运这块避免全屏BitBlt的带宽浪费。1080P 全屏BitBlt一次大约 13ms局部刷新能压到 0.3ms 以内。参数说明m_hBmpBack用CreateDIBSection创建而不是CreateCompatibleBitmap。原因很实际——CreateCompatibleBitmap得到的是设备相关位图没法直接拿pBits指针做逐像素处理而边缘混合算法必须能直接读写像素内存。CreateDIBSection返回的void** ppvBits让这一切成为可能。4.2 脏矩形只重算变化的那一块超采样的代价和面积成正比脏矩形就是把面积压下去的武器。示例场景里维护一个std::vectorRECT每次内容变化把受影响的区域丢进去渲染时合并重叠区域再处理// 合并脏矩形减少 StretchBlt 调用次数 void CCanvas::MergeDirtyRects(std::vectorRECT vRects) { if (vRects.size() 2) return; // 简单合并反复扫描能合并就并直到一轮没有变化 bool bMerged true; while (bMerged) { bMerged false; for (size_t i 0; i vRects.size(); i) { for (size_t j i 1; j vRects.size(); j) { RECT rcUnion; UnionRect(rcUnion, vRects[i], vRects[j]); LONG nAreaU (rcUnion.right - rcUnion.left) * (rcUnion.bottom - rcUnion.top); LONG nAreaS (vRects[i].right - vRects[i].left) * (vRects[i].bottom - vRects[i].top) (vRects[j].right - vRects[j].left) * (vRects[j].bottom - vRects[j].top); // 合并后膨胀不超过 1.5 倍才值得并 if (nAreaU nAreaS * 3 / 2) { vRects[i] rcUnion; vRects.erase(vRects.begin() j); bMerged true; j i; } } } } }逻辑说明两个矩形如果离得远合并后中间一大片空白也要重算反而更慢。所以设了个「膨胀不超过 1.5 倍」的门槛超过就让它们各自独立处理。参数说明3/2这个系数可以调。场景稀疏比如几个分散的小控件在动时用 1.2 更省场景密集时用 2.0 让合并更积极、减少调用次数。4.3 耗时实测与降级策略示例工程带一个CQpcTimer每次渲染循环记一次耗时窗口标题栏实时显示。在测试机上i5 独显、1920×1080跑出来的大致数据场景4x SSAA 全屏4x SSAA 脏矩形2x SSAA 全屏边缘混合静态图表14.2 ms1.8 ms局部4.1 ms6.5 ms拖动缩放38 ms12 ms9 ms8 ms从数据能看出两件事全屏 4x 超采样在拖动时直接掉到 26FPS必须靠脏矩形救边缘混合算法耗时和内容复杂度关系不大但全屏跑一次也要 6ms 以上因为它扫的是全像素。降级策略写在Canvas::OnFrame里连续 3 帧超过 16.7ms 就把超采样倍数从 4 降到 2再超就切成边缘混合。这是很土的自适应但现场用足够——用户感知不到模式切换只会觉得「拖动比刚才顺」。真要做得精细得按内容类型判断几何图形密集的帧走 SSAA位图密集的帧走边缘混合。5. 排查清单GDI 抗锯齿最容易翻车的五个现场这套东西看着简单但 GDI 的状态机很老坑基本都藏在「你以为设了其实没生效」里。下面五条是我自己踩过、也在别人代码里复现过的。5.1 现象缩小后的图有摩尔纹边缘更脏了原因SetStretchBltMode(HALFTONE)调了但没调SetBrushOrgEx。GDI 的HALFTONE模式依赖「刷子原点」来决定采样网格从哪儿开始如果这个原点还停在上次绘制遗留的位置采样网格就偏了产生规律性条纹。这是最典型的玄学问题现象看着像算法坏了其实是个状态没归零。解决每次SetStretchBltMode之后紧跟一句SetBrushOrgEx(hdc, 0, 0, nullptr)。两句话必须成对出现跟记事本里打括号一样。5.2 现象设了 HALFTONE效果还不如不设原因SetStretchBltMode设置的是目标 DC的模式不是源 DC 的。很多人把hdcBig源设了一遍hdcTarget压根没动实际走的还是COLORONCOLOR最近邻。更隐蔽的是如果目标 DC 是窗口 DC别的绘制代码可能在后面又把它改回去了。解决SetStretchBltMode一定要作用在最终接收图像的那个 DC 上并且调用前先保存原值、调用后恢复防止污染调用方。这也是为什么 3.1 节的示例里专门存了nOldMode。5.3 现象跑几分钟后界面卡死任务管理器里 GDI 对象数一路涨原因GDI 对象泄漏。最常见的三种CreateCompatibleDC后忘了DeleteDCSelectObject换进去的 HBITMAP 没换回来就删CreateDIBSection的位图在窗口关闭时还挂在 DC 上。GDI 对象上限默认是每进程 10000 个涨到上限所有绘制调用全部失败且不报错。解决给CDibSection写析构函数做 RAIISelectObject一律存旧句柄、用完还原。另外把任务管理器加上「GDI 对象」列跑压力测试时盯着看——稳定不涨才敢交付。5.4 现象高 DPI 屏上边缘还是糊或者位置整体偏移原因程序没声明 DPI 感知Windows 把 1920×1080 的绘制结果拉伸到 2560×1440 再显示前面做的所有抗锯齿都被系统级双线性插值覆盖了。另一种情况是声明了感知但坐标还按 96DPI 写死控件位置全错。解决在 manifest 里声明PerMonitorV2或者启动时SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)。声明之后所有坐标按物理像素算超采样倍数也要跟着调整——高 DPI 下 2 倍超采样就够因为屏幕本身像素密度高。5.5 现象屏幕上看着没问题截图或打印出来锯齿又回来了原因抗锯齿处理只作用在「屏幕渲染路径」上导出位图和打印走的是另一条HDC没经过EndDraw那道工序。这是架构问题不是 bug——渲染管线和导出管线分叉了。解决把抗锯齿封装在EndDraw里是对的但导出时也必须走同一个Renderer实例。搞一个统一的RenderTo(HDC hdc, int nW, int nH)入口屏幕、截图、打印全部从这儿出别各写一套。这是「后悔药」级别的设计等发现导出效果不对再返工改动面会很大。6. 二次开发把抗锯齿做成可插拔的渲染后端代码拿到手最常改的两件事换算法、加内容类型。把这两件事做得顺手的前提是接口边界划清楚而这条边界就在Renderer.h那个只有三个虚函数的抽象类上。6.1 抽象接口的取舍接口设计上刻意没把「绘制什么」放进来只留生命周期管理因为绘制调用的形态千变万化一旦塞进接口就会变成巨型类。实际的做法是调用方通过GetDC()拿到一个 HDC 自己在上面画画完调EndDraw。class IRenderer { public: virtual ~IRenderer() {} // 内容尺寸变化时重建离屏资源 virtual void Resize(int nW, int nH) 0; // 返回绘制用 DC调用方在上面正常使用 GDI 绘图 API virtual HDC BeginDraw() 0; // 收尾执行抗锯齿并把结果输出到目标 DC virtual bool EndDraw(HDC hdcTarget, const RECT rcDst) 0; // 便于日志和调优时区分当前后端 virtual const wchar_t* Name() const 0; };逻辑说明BeginDraw返回的 HDC 在 SSAA 后端里是 4 倍大图的 DC调用方不需要知道自己画在多大的画布上坐标照旧按逻辑尺寸给——所以BeginDraw内部要顺手做一次SetMapMode或SetWorldTransform缩放。这是整个设计里最省事的一点业务代码零改动。参数说明Resize里必须把旧的HBITMAP/HDC全释放再重建否则改窗口大小时内存会一路涨。EndDraw返回布尔值方便上层在失败时降级到「直接 BitBlt 不做抗锯齿」。6.2 加一个 3×3 卷积后端想加个自定义算法照着下面这个骨架写就行不用碰Canvas和main.cpp// RendererConvolution.cpp —— 固定核的 3x3 平滑 class CRendererConvolution : public IRenderer { public: void Resize(int nW, int nH) override { /* 重建 DIB */ } HDC BeginDraw() override { return m_hdcBack; } bool EndDraw(HDC hdcTarget, const RECT rcDst) override { // 核{1,2,1, 2,4,2, 1,2,1} / 16轻微模糊 static const int k[9] {1,2,1, 2,4,2, 1,2,1}; Convolve3x3((uint32_t*)m_pBits, m_nW, m_nH, k, 16); return BitBlt(hdcTarget, rcDst.left, rcDst.top, rcDst.right - rcDst.left, rcDst.bottom - rcDst.top, m_hdcBack, rcDst.left, rcDst.top, SRCCOPY) ! FALSE; } const wchar_t* Name() const override { return LConvolution3x3; } };逻辑说明EndDraw里先在像素缓冲上做卷积再BitBlt输出。核的总和必须等于除数 16否则整体亮度会变。这个方法的问题是全画面都会糊不区分边缘效果上比 3.2 节的边缘检测差一截但代码短、易读适合作为二开练手的起点。参数说明核数组换成正的锐化核{0,-1,0, -1,5,-1, 0,-1,0}除数 1就是锐化但会让锯齿更明显别用在边缘密集的内容上。除数不够大时会出现数值溢出Convolve3x3内部做了 clamp 到 0255不会出现花屏。6.3 效果验证别靠肉眼用数据说话判断抗锯齿有没有真的生效最稳的办法是统计「中间灰阶像素」的比例。画一组 1 像素宽的斜线在白底上纯黑是 0、纯白是 255如果抗锯齿生效边缘必然出现大量 1254 之间的值// 统计一幅 32bpp 位图中「中间灰阶」像素占比 double MiddleGrayRatio(const uint32_t* p, int nCount) { int nHit 0; for (int i 0; i nCount; i) { int nLuma ((p[i] 0xFF) * 77 ((p[i] 8) 0xFF) * 150 ((p[i] 16) 0xFF) * 29) 8; if (nLuma 8 nLuma 247) nHit; } return (double)nHit / nCount; }实测下来未做处理的斜线图这个比例在 0.3% 以下2x SSAA 约 2.5%4x SSAA 约 5.8%边缘混合约 4%。如果改了算法但数字没动说明处理根本没走到先查EndDraw有没有被调用、目标 DC 是不是拿对了。从那次折线图的现场回来之后我养成一个习惯凡是涉及 GDI 缩放或像素处理的改动改完先跑一遍MiddleGrayRatio再看屏幕。眼睛会被「好像顺眼了」骗数字不会。上面这套接口和验证方法配合着用换算法基本就是写一个类、注册进去、跑一次统计十几分钟的事。希望帮到你。本文还有配套的精品资源点击获取