简介：面向Windows GDI图形编程者的实时抗锯齿源码包，适合使用VC++绘制曲线、斜线、椭圆等图形并受到边缘锯齿困扰的开发者参考。资源针对LineTo、Ellipse等函数因像素格限制产生的明显锯齿，提供可运行的抗锯齿实现与演示程序：先识别边界像素，再按距离或邻域权重混合颜色以平滑过渡，同时涉及多级采样、SIMD并行、预计算缓存以及按分辨率、色深和系统性能动态调整策略等优化思路。压缩包共69个文件，约312KB，主要由gif、png、jpg效果图与网页素材，js、htm、css展示页面，以及zip格式的源码和演示包构成，便于对照阅读、运行验证和观察处理前后差异。已有848人学习下载，可作为理解GDI抗锯齿原理、比较实时效果并提炼工程优化方法的实践参考。

1. GDI 斜线为什么必然带锯齿：缺少覆盖率概念的硬光栅化

很多人的第一反应是「锯齿是分辨率不够」，把窗口拉大、把位图加大，台阶就该细到看不见。这个判断在 GDI 上不成立：把同一段 LineTo 画到四倍尺寸的位图上再缩回来，边缘的台阶仍然原样存在。问题不在像素密度，而在 GDI 的光栅化模型——Bresenham 只回答「这个像素点属不属于这条线」，从不回答「这个像素有多大比例属于这条线」。像素在模型里是一个数学点，不是一个有面积的方块，于是每次写入只有全亮和全暗两种结果，中间那档被整块丢掉了。

真实世界里，一条线有宽度、像素也有面积，两者相交的面积占比本该映射成灰度，这条被丢弃的信息就是锯齿的全部来源。所以要实时消除锯齿，做的不是「加像素」，而是给每一次写入补回那个覆盖率系数——后面几章沿着这条线，从面积采样的原理一路拆到直接改写 DIB 内存的源码实现。

2. 抗锯齿的本质是面积采样：覆盖率、混合方程与 GDI+ 的性能账

锯齿是信息损失，抗锯齿就是把这部分信息找回来。还原方式有三条路：解析求交、超采样统计、查表逼近。三条路的成本差一个数量级以上，选错了，实时性直接翻车。

2.1 覆盖率从哪里来：解析法、超采样与查表法

解析法对直线特别便宜。假设线宽 1 像素、斜率绝对值不超过 1，那么沿 x 轴每前进一列，线在这一列像素内沿 y 方向扫过的位置就是一个浮点数，整数部分决定落在哪一行，小数部分恰好近似等于它在该行内占据的高度比例。也就是说，一个浮点坐标的尾数就白送了一个覆盖率，不需要任何几何求交运算。这是 Wu 直线算法的全部理论基础，后面第 4 章的全部优化都是围绕「怎么更快地拿到并消费这个尾数」展开的。

对圆、贝塞尔曲线、多边形这类图元，解析法就贵了，需要算每个像素被裁剪后的面积，一般退化成扫描线加区间累加。超采样则是另一条思路：把每个像素虚拟切成 N×N 个子采样点，统计落在图元内部的点数，得到 N²+1 级灰度。2×2 只有 5 级灰度，台阶虽然变淡但肉眼仍能分辨；4×4 有 17 级，基本够用；8×8 的 65 级质量很好，但填充成本是 64 倍，只适合导出图片时离线跑。查表法介于两者之间，把斜率量化成 256 档，预先算好每一档在一个周期内（斜率为有理数时是有限周期）的覆盖率序列，运行时只查表不计算，代价是一次内存访问换来若干次浮点运算。

三种方法的共同前提是：像素必须被当成有面积的单元。这是判断一份抗锯齿代码是否合格的第一标准——如果它还在用 SetPixel 逐点写死颜色，那它顶多是把线画细了，没有真正做覆盖。

2.2 混合方程与预乘 Alpha：dst = src·a + dst·(1−a) 为什么不能省

拿到覆盖率 a 之后，写入动作就不再是赋值，而是混合。设目标像素原有颜色为 B，前景色为 F，覆盖率为 a，正确结果是F·a + B·(1−a)。a=0 时像素保持原样，a=1 时完全变成前景，中间线性过渡——这正是「面积加权平均」的数学表达，物理上对得上。

这里有个必须读背景的隐含条件：像素缓冲区里本来就有东西。如果画之前没把背景完整铺到位图上，读到的就是未初始化的 0（黑色），混合结果会把线上的每个半透明像素都往黑里拉，边缘出现一圈脏边。很多人第一次写抗锯齿就栽在这，以为是算法错了，其实是缓冲区是空的。

预乘 Alpha 是这套公式的工程化变体。把源颜色事先乘上 a，公式变成src' + dst·(1−a)，少一次乘法，而且1−a可以做成 256 项的查找表。更关键的是多次叠加时预乘不会溢出：非预乘格式下两个半透明色叠加需要除法归一化，预乘格式直接相加即可，这也是AlphaBlend要求AC_SRC_ALPHA源位图必须是预乘格式的原因。

整数实现里还有个血泪细节。用(x·a + y·(255−a)) >> 8代替除以 255，速度快但结果偏小约 0.4%，一次两次看不出来，几十层叠加之后暗部会明显发灰。要么加 128 做四舍五入补偿，要么直接查表：

// 256 项混合查找表：blend[(a << 8) | v] = v * a / 255 static BYTE g_blend[256 * 256]; inline void InitBlendLUT() { for (int a = 0; a < 256; ++a) for (int v = 0; v < 256; ++v) g_blend[(a << 8) | v] = (BYTE)((v * a + 127) / 255); } // 混合一个通道：dst 是目标，src 是前景，a 是覆盖率 inline BYTE BlendChannel(BYTE dst, BYTE src, BYTE a) { return g_blend[((255 - a) << 8) | dst] + g_blend[(a << 8) | src]; }

这张表占 64KB，能塞进 L2 缓存，命中率极高。参数a是覆盖率，取 0 到 255；dst/src是单通道字节值；两次查表相加的结果必然不超过 255，因为(255−a)+a = 255，不会溢出。用查表换来的是无分支、无浮点、可向量化的混合路径，比运行时算除法快一个数量级。

2.3 为什么 GDI+ 的 SmoothingMode 不敢用在实时刷新里

看到这里很容易想到：GDI+ 不是有SmoothingModeAntiAlias吗，一行设置就完事。静态出图确实可以这么干，但实时刷新的场景里这个选项很难扛住。

第一，GDI+ 的抗锯齿走的是它自己的软件光栅器，不依赖 GPU。设置SmoothingModeAntiAlias之后，DrawLine/DrawPath内部不再转发给 GDI，而是由 GDI+ 逐像素做覆盖率计算和混合。在每秒重绘几十帧的波形图或矢量图场景里，绘制几千条线段时这层额外的软件路径开销会非常明显，帧时间随图元数量线性上涨。

第二，GDI 与 GDI+ 混用时有状态边界。从 HDC 构造Graphics对象会带来一次绘制状态快照，之后用 GDI 画的图和用 GDI+ 画的图在同一个位图上混合，alpha 通道的处理规则并不一致——GDI 的BitBlt根本不认 alpha 字节，GDI+ 认。一旦两条路径都往同一块 32 位位图上写，边缘就会出现明暗不接的接缝。

第三，细粒度控制权不在你手上。线宽补偿、gamma 校正、脏矩形裁剪这些实时场景必备的手段，GDI+ 一概不开放。所以真要做实时抗锯齿，主流做法是绕开系统绘制函数，自己拿像素缓冲，第 3 章讲怎么把这块内存拿到手。

3. 绕开绘制函数直接改内存：DIB Section 的像素指针与 Stride 布局

3.1 CreateDIBSection 拿到的那根指针到底指向什么

CreateCompatibleBitmap创建的是设备相关位图（DDB），像素格式和内存布局由显示驱动决定，应用层拿不到指针，只能靠 GDI 函数去画。CreateDIBSection不一样，它在返回HBITMAP的同时，通过第四个参数回传一个可以直接寻址的像素缓冲区首地址。

// 创建与屏幕兼容的内存 DC HDC hMemDC = CreateCompatibleDC(hdcScreen); BITMAPINFO bi = {}; bi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); bi.bmiHeader.biWidth = width; bi.bmiHeader.biHeight = -height; // 负值 = 自上而下，行 0 在顶部 bi.bmiHeader.biPlanes = 1; bi.bmiHeader.biBitCount = 32; // 32 位才有稳定的 BGRA 布局 bi.bmiHeader.biCompression = BI_RGB; void* pBits = nullptr; HBITMAP hBmp = CreateDIBSection(hMemDC, &bi, DIB_RGB_COLORS, &pBits, nullptr, 0); HGDIOBJ hOld = SelectObject(hMemDC, hBmp); // 一行字节数按 4 字节对齐 int stride = ((width * bi.bmiHeader.biBitCount + 31) / 32) * 4;

biHeight取负值是关键。正值表示 bottom-up DIB，第 0 行在图像底部，写像素时得做(height - 1 - y)翻转，漏掉这一步的后果是整幅图上下颠倒，而 GDI 绘制函数画出来的内容方向又是对的，两者叠在一起就是镜像错位。取负值直接得到 top-down 布局，行序与屏幕坐标一致，pBits + y * stride就是第 y 行的起点。

这块内存不是普通堆内存，它同时被 GDI 子系统认可，可以BitBlt到窗口上，也可以被AlphaBlend当作源。像素数据只存一份，没有从「自己算的图」到「GDI 能画的图」的拷贝过程，这是实时性的基础。

3.2 32 位 BGRA 的字节序与 Stride 对齐陷阱

32 位BI_RGB的 DIB，每像素 4 字节，内存里的顺序是 B、G、R、A。把它当 DWORD 读出来是0xAARRGGBB，所以写p[0]改的是蓝通道，写p[2]才是红通道。搞反了的表现是整张图红蓝互换，人脸发蓝，一眼能看出来。

第四字节 alpha 的行为要特别当心。用 GDI 的BitBlt把这张位图贴到屏幕上时，alpha 字节被完全忽略，像素按 BGR 直接覆盖目标；只有用AlphaBlend并指定AC_SRC_ALPHA时才读它，而且要求源位图是预乘格式。所以常见做法是：内部抗锯齿全程把 alpha 填 0xFF 避免出现黑边，需要整层透明度时再单独走AlphaBlend那条路。用错组合的典型症状是「明明画上去了，屏幕上一片黑」——因为BitBlt不认 alpha，而位图某些区域 alpha 是 0，源数据本身颜色又是 0。

Stride 对齐在 32 位下恰好等于width * 4，看起来没有坑，但只要哪天为了省内存改成 24 位，坑立刻出现：24 位 DIB 每行按 4 字节对齐，行尾有填充字节，width * 3直接算行偏移会逐行累积错位，图像越往下越斜，像被斜切了一样。写死stride变量、永不手算width * 4，是最便宜的自保手段。

3.3 SetPixel 与直接写内存的性能差距从哪来

SetPixel每次调用都是一次 GDI 调用。它要经过句柄表查找、参数封送，进入图形子系统的绘制路径，即便有批处理机制把同一批次内的调用排队，单点写入依然无法被编译器优化成批量操作。一帧里写十万个像素，就是十万次函数调用外加十次以上的参数检查，卡顿到个位数帧率属于正常现象。

直接操作pBits则是纯 CPU 内存写入：一条mov指令，地址由pBits + y * stride + x * 4算出，编译期就能把四次字节写合并成一次 32 位写，循环还能被自动向量化，配合顺序访问的预取行为，吞吐能贴着内存带宽跑。

// 直接写 DIB 像素：一次 32 位写入代替四次 SetPixel inline void PutPixel32(BYTE* pBits, int stride, int x, int y, BYTE r, BYTE g, BYTE b) { BYTE* p = pBits + y * stride + x * 4; p[0] = b; p[1] = g; p[2] = r; p[3] = 0xFF; // 保持 alpha 为 255，避免 BitBlt 出现黑块 } // 对比：GDI 路径，同一次刷新里调用十万次，量级差异在两到三个数量级 // ::SetPixelV(hMemDC, x, y, RGB(r, g, b));

两者的差距不是常数倍，而是随像素数量放大的量级差。这也解释了一个常见现象：同样的抗锯齿算法，有人写出来流畅，有人写出来卡顿，差别往往不在算法本身，而在写入通道选的是SetPixel还是内存指针。

4. Wu 直线的实时化改造：定点化、增量步进与边界裁剪

4.1 原始 Wu 算法：用端点小数部分拆成两档亮度

算法的核心只有一句话：沿主轴步进，每个像素列上一个精确落点，按落点的小数部分把亮度拆给相邻两个像素，两档亮度之和恒为 1。

设斜率绝对值不超过 1，沿 x 步进。在某一列 x 处，线的精确纵坐标是浮点值 y，取整数部分iy和小数部分fy。那么(x, iy)这一行被线覆盖的高度是1−fy，(x, iy+1)被覆盖的高度是fy。把这两个比例直接当覆盖率去做混合，就能得到一条亮度沿垂直方向连续过渡的线。

斜率超过 1 时沿 y 步进更划算，做法是对调 x/y 坐标，算完再换回来。这不仅是效率问题，更是正确性问题：如果不换轴而硬按 x 步进，同一个像素列内会出现多次写入，重复混合导致局部偏亮，线条上出现周期性亮点，看起来像虚线。

这个近似之所以成立，是因为「列内倾斜被忽略」的误差在斜率不超过 1 时很小——线在单个像素列内的横向偏移不超过 1 个像素，对覆盖面积的二阶影响可以忽略。斜率越大误差越大，换轴把那部分误差重新压回可接受的范围，这就是为什么steep判断必须放在最前面。

4.2 改造一：浮点转定点，用整数移位替代 floor 和 round

原始 Wu 是教学代码，满屏floorf、fabsf、roundf。这些函数每次调用都有分支判断和特殊情况处理，在一个跑了十万次的循环里，开销比混合本身还高。工业级实现在这里统一换成 16.16 定点数：高 16 位是整数部分，低 16 位是小数部分，floor退化成右移 16 位，取小数部分退化成按位与0xFFFF，四舍五入退化成加0x8000再右移。

覆盖率的提取同样走移位：小数部分右移 8 位得到 0 到 255 的值，直接喂给上一章的混合查找表。整个主循环里除了初始化那一小段，不出现任何浮点运算。

定点化的收益不只是速度。浮点在 x87 与 SSE 之间切换、编译器不同的优化级别，会让结果产生末位差异，同样的代码在两台机器上画出的亮度略有不同，联调时很难对齐。定点数是确定性的，同样的输入在任何机器上得到逐比特一致的结果，这对需要截图比对、回归测试的绘图软件来说是刚需。

4.3 改造二：增量式主循环、边界裁剪与避重混合

浮点版本每步都要重算y = y0 + gradient * (x - x0)，一次乘法一次加法。增量式把这一步换成一次加法：维护当前 y，每前进一列就y += gradient。误差会累积，但在 16.16 定点下每步的截断误差不超过 1/65536 像素，一条两千像素长的线累积误差不到 0.03 像素，肉眼不可见。

边界裁剪必须放在主循环之前，不能靠循环内的if判断。原因有两个：一是每像素一次分支会拖慢流水线；二是超出缓冲区的坐标会直接踩坏堆内存，表现为随机崩溃或画面上出现诡异色块，排查起来极其费时。用 Liang-Barsky 把线段先裁到视口矩形内，再进主循环，循环体内就可以放心地不做边界检查。

// 在 32 位 top-down DIB 上绘制抗锯齿直线 // pBits: DIB 像素首地址 stride: 行字节数 (x0,y0)-(x1,y1): 已裁剪的端点 inline void WuLine32(BYTE* pBits, int stride, float x0, float y0, float x1, float y1, BYTE r, BYTE g, BYTE b) { bool steep = fabsf(y1 - y0) > fabsf(x1 - x0); if (steep) { // 斜率大于 1 时交换轴，保证沿主轴步进 std::swap(x0, y0); std::swap(x1, y1); } if (x0 > x1) { // 统一成从左到右，避免两个分支 std::swap(x0, x1); std::swap(y0, y1); } float dx = x1 - x0; float dy = y1 - y0; float gradient = (dx == 0.0f) ? 1.0f : dy / dx; // 每列 y 的增量 // 从第一个整数列开始，算出该列上的精确 y float y = y0 + gradient * ((float)(int)(x0 + 0.5f) - x0); int xe = (int)(x1 + 0.5f); for (int x = (int)(x0 + 0.5f); x <= xe; ++x) { int iy = (int)floorf(y); float fy = y - (float)iy; // 小数部分即下方像素的覆盖率 if (steep) { PutPixelBlend(pBits, stride, iy, x, r, g, b, 1.0f - fy); PutPixelBlend(pBits, stride, iy + 1, x, r, g, b, fy); } else { PutPixelBlend(pBits, stride, x, iy, r, g, b, 1.0f - fy); PutPixelBlend(pBits, stride, x, iy + 1, r, g, b, fy); } y += gradient; // 增量步进，替代每步乘法 } }

参数含义：pBits与stride共同决定行寻址，stride必须是 DIB 的真实行字节数而不是width * 4；四个端点坐标必须是裁剪后的浮点值，浮点保留是为了让端点也落在半像素位置上；r/g/b是前景色，不透明度由两档覆盖率之和恒为 1 保证。

PutPixelBlend内部就是第 2 章那张混合查找表加一次越界检查（如果裁剪做在前面，这里可以省掉）。循环体的关键性质是：每个像素列只写一次、写两个像素、两个像素的覆盖率之和恰好为 1。这一条保证了整条线的「总能量」与角度无关——不管线是水平、45 度还是接近垂直，它占用的总亮度是一样的，视觉上不会出现「斜线比横线淡」的现象。

5. 实时抗锯齿的常见问题排查：从颜色发灰到帧率骤降

5.1 像素层面的三个坑

现象一：抗锯齿线明显比旁边 GDI 画的线更淡更细，像是褪色了。原因是 Wu 只给覆盖像素分配覆盖率亮度，1 像素宽的线在实际覆盖时，每个像素的覆盖率平均下来往往不到 1，整条线的感知亮度下降。人眼对亮度是非线性的，线性分配的覆盖率在暗背景上看起来更细。解决方式是做线宽补偿和 gamma 校正：把有效线宽从 1.0 提到 1.3 左右，并把覆盖率a映射成pow(a, 1/2.2)的近似查表值，肉眼感知的粗细立刻恢复正常。

现象二：线条周围有一圈脏黑边，尤其在半透明区域最明显。原因是混合时读到的背景是 0。缓冲区在画线之前没有铺过背景，dst通道全是 0，dst·(1−a)这一项把像素往黑色拉。解决很简单：每帧开始先用BitBlt把背景完整贴到 DIB 上，或者用一个背景位图做SRCCOPY拷贝，然后再叠加前景抗锯齿。顺序不能反，反了就是把背景盖在线上。

现象三：两条线相交或首尾相接的地方出现白点。原因是每条线独立做 over 混合，交叉处同一个像素被混合了两次，(1−a1)(1−a2)的残留让颜色叠加超出预期，亮色线上就表现为白点。正确做法是把当前帧所有图元先画到一个独立的、初始化为全透明的图层上，最后整体做一次AlphaBlend合成到底图；如果嫌图层开销大，退而求其次的办法是对交点附近的像素做饱和加法而不是 over 混合。

5.2 性能与资源层面的两个坑

现象四：算法单独测很快，集成进绘图窗口后帧率掉到个位数。两种典型原因。一是每帧都在CreateDIBSection，创建和销毁位图本身要走 GDI 对象管理，每帧几十微秒乘以图元数量就积少成多了，正确做法是窗口尺寸变化时才重建，平时复用。二是每帧全额重绘整个视口，而实际变化的可能只有一个角落，配合脏矩形只重绘变化区域，成本能压到原来的几十分之一。用GetClipBox拿到需要重绘的区域，把所有绘制调用裁剪到这个矩形内，是最省力的优化。

现象五：程序跑几个小时后画面开始花屏，重启才恢复。这是 GDI 对象泄漏的典型症状。CreateDIBSection返回的HBITMAP、CreateCompatibleDC返回的HDC、SelectObject换下来的旧对象，三样东西只要漏掉一样，进程的 GDI 句柄数就会缓慢上涨，撞到上限之后所有绘制调用静默失败。解决办法是用 RAII 把句柄包起来，在析构里SelectObject(hOld)再DeleteObject，并且养成习惯：只要写了Create或Select，同一屏代码里就必须能找到配对的释放。

注意：GDI 句柄配额是进程级的，泄漏不会立刻报错，只会在长时间运行后突然集体失效。调试期可以在任务管理器里盯住「GDI 对象」这一列，正常应该稳定在一个常数附近波动，持续单调上涨就说明有泄漏。

6. 方案取舍：解析抗锯齿、超采样与后处理该怎么选

6.1 三种路线的成本结构对比

表格里最值得说的是最后一行。后处理思路（扫一遍位图找边缘、对边缘像素做方向性模糊）的好处是它不关心图元是什么，任何来源的位图都能处理，适合把一张已经画好的、带着锯齿的位图救回来。代价是它分不清「锯齿台阶」和「真实锐利边缘」，一张包含文字和细密纹理的图经过它处理，文字会发虚、纹理会被抹平，观感反而下降。它适合用在「图元已经画完、但不想改动绘制管线」的维护型项目里，不适合当作主方案。

6.2 让成本只跟变化面积成正比

真正的实时性从来不来自算法本身有多快，而来自「不做无用功」。把脏矩形裁剪做到位，一帧里需要重绘的往往只占整个视口很小一块，抗锯齿的绝对开销就跟着降下来。配合三层结构——背景层缓存不动、图元层按脏矩形重绘、最后一次性合成——即便用较贵的超采样，在小区域内也是可接受的。

反过来，如果每帧都全屏重绘，那无论选哪种方案都会在某个图元数量级上撞墙。这也是为什么很多绘图软件在缩放、拖拽时关闭抗锯齿、松手后再补一帧高质量渲染：交互过程要的是响应，静止画面才要质量，两者不必用同一套参数。

有一个细节容易被忽略：抗锯齿的端点在缩放时会暴露出来。Wu 算法对端点不做特殊处理，线段两端的覆盖率按斜率自然衰减，短线段在放大后看起来像被削尖了。如果绘制的是封闭图形或者需要精确对接的线，端点要做成圆头或者按角度补偿，这部分代码量不大，但决定了整张图在放大后是否经得起看。

从那以后我每次接入一条新的绘制路径，都会先用一条 30 度的 1 像素斜线在纯色背景上走一遍，把截图放大 8 倍逐像素看覆盖率是否连续、端点是否收得干净、交界处有没有重复混合的白点——这三项过了，再谈性能优化。这份源代码里的工程把 Wu 直线、DIB 直写、脏矩形增量刷新这几条路径都串好了，配合断点单步走一遍主循环，比看十页公式都直观。希望帮到你。

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