简介面向 Windows GDI 绘图开发者的抗锯齿实战代码包适合具备 Win32 与 VC 基础、需要提升界面绘制质量的中级开发者针对使用 LineTo、Ellipse 等接口绘制斜线与曲线时出现的像素锯齿问题给出可嵌入项目的实时优化思路与实现参考。压缩包共 69 个文件约 312KB以 gif、png、jpg 等效果图与界面素材js、htm 说明页面以及 css 样式和 zip 源码/演示包为主便于先看效果再对照代码。已有 848 人学习。内容围绕边缘检测、邻域颜色加权混合、多级采样展开并兼顾 SIMD 并行、预计算缓存与分辨率、色深自适应等性能策略同时保留可调节的采样范围与强度参数方便按场景平衡画质与开销配套说明文档、源码包和演示程序可帮助开发者理解抗锯齿流程、对比处理前后边缘过渡、验证绘制效果并迁移到自有 GDI 绘图模块中。1. 斜线放大四倍之后一份纯 GDI 的实时抗锯齿源码补的是哪一层用 VC 和 GDI 写过绘图工具的人大多见过这个画面窗口缩放到 400%一条 45 度斜线立刻变成一串整齐的台阶圆的边缘像被啃过。GDI 的LineTo、Polygon、Ellipse只认像素格子没有“覆盖率”这个概念原生就不带抗锯齿。这份 GDI 实时消除图像锯齿的源代码干的就是在纯 GDI 的地基上把这一层补回来。它不是 GDI 里SmoothingMode的封装也不是把整幅图丢给第三方渲染库而是自己维护一块 32 位 DIB 内存画布用“几何图元算覆盖率 位图超采样降采样”两条路径把台阶处理平滑最后一次性贴回窗口。适合正在写截图标注、工业组态、矢量图元编辑器这类桌面程序的开发者尤其是那些被“只能用 GDI、不能引 GDI 或别的渲染引擎”约束住的场景。源码是 VC 工程编译出来就能看到开关抗锯齿的前后对比也能把其中两三个类单独提取出来塞进自己的绘制模块。下面按“是什么、怎么跑、怎么改”的顺序拆开讲。2. 架构拆解一块 32 位 DIB 撑起来的两级抗锯齿管线整套代码不复杂核心思路就一句话所有绘制先落到一块比窗口大 N 倍的内存位图上画的时候该算覆盖率的算覆盖率最后统一缩回窗口尺寸。抗锯齿的“平滑”实际上是两件事拼起来的——矢量图元靠解析式覆盖率位图靠超采样后的均值滤波。2.1 目录结构与模块职责工程不大文件划分基本围着一条渲染管线转。你下载到的版本文件名可能略有出入但职责切分大体是这样模块职责关键接口画布模块管理 DIB、像素混合、降采样贴屏Create/BeginFrame/EndFrame直线与曲线Wu 直线、圆、Bezier 采样DrawLineAA/DrawCircleAA多边形填充扫描线 边覆盖率累积FillPolygonAA主窗口/视图消息循环、脏矩形收集、重建时机OnPaint/OnEraseBkgnd这里的分层有个明确的好处画布模块完全不知道上面画的是什么它只提供“按覆盖率混合一个像素”这一个原语线、圆、多边形都建在这个原语之上。二次开发时你新增图元只需要算出每个像素的 alpha不用碰 DIB 管理和贴屏逻辑。画布对象在窗口整个生命周期里只应该创建一次尺寸变化时才重建。我见过的多数性能问题都是因为在WM_PAINT里顺手CreateDIBSection造成的——那块内存的分配和清零成本远比你想的高更别说你还在里面 SelectObject、DeleteObject 来回折腾。2.2 一帧的生命周期从 BeginFrame 到 StretchBlt一帧的链路是固定的四步取画布 DC → 按逻辑坐标画 → 算脏矩形 → 降采样贴到窗口 DC。视图层的OnPaint大致长这样void CGdiAAView::OnPaint() { CPaintDC dc(this); CRect rcClient; GetClientRect(rcClient); // 只有尺寸变了才重建画布别每帧都 Create/Delete if (m_canvas.GetWidth() ! rcClient.Width() || m_canvas.GetHeight() ! rcClient.Height()) { m_canvas.Create(m_hWnd, rcClient.Width(), rcClient.Height(), 2); m_dirty rcClient; // 尺寸变了整屏作废 } HDC hdcBuf m_canvas.BeginFrame(); RedrawScene(hdcBuf); // 自己图元的绘制入口坐标一律逻辑坐标 RECT rc m_dirty.IsRectEmpty() ? (RECT)rcClient : (RECT)m_dirty; m_canvas.EndFrame(dc.m_hDC, rc); // 降采样 贴屏 m_dirty.SetRectEmpty(); } BOOL CGdiAAView::OnEraseBkgnd(CDC* pDC) { return TRUE; // 背景由画布自己填交回系统擦会闪 }OnEraseBkgnd直接返回TRUE是必须的。画布本身已经是一块完整的双缓冲让系统再用背景刷擦一遍等于每帧多一次全屏填充闪屏也就跟着来了。RedrawScene里拿到的hdcBuf是内存 DC坐标系是逻辑坐标图元函数内部自己乘采样倍率这样上层的业务代码不需要关心倍率是 1 还是 4。2.3 两条抗锯齿路径的分工几何用 Wu位图用超采样为什么不是一套方案打天下因为成本和效果完全不对称。几何图元线、圆、曲线、多边形边界适合解析式覆盖率一条线经过哪些像素、每个像素被覆盖了多少比例是可以直接算出来的。Wu 直线就是这个思路的经典实现复杂度跟线长成正比跟采样倍率无关1 倍分辨率下也能出好效果而且缩放窗口时不会糊。位图、渐变填充、贴图这类内容没有解析式只能靠超采样先把内容画到 2 倍或 4 倍的缓冲上再整体缩回来缩小过程本身就是一个均值滤波边缘自然被平均出灰度过渡。代价是像素填充量按倍率的平方增长。两条路径共处同一块 DIB。这意味着几何图元在 2 倍缓冲上画时中心点要偏移(scale-1)/2个物理像素让线条落在像素中心而不是格线上否则 1 像素宽的线在偶数倍率下会横跨两个物理像素反而更粗更糊。这个偏移量在很多同类代码里被漏掉是肉眼可见的差别。3. 核心代码从 CreateDIBSection 到 BlendPixel 的逐像素落地原理说完落到代码。这一段是整份源码最值得抄的部分也是改造时你最可能动的地方。3.1 建画布CreateDIBSection 与自上而下的 DIBBOOL CSmoothCanvas::Create(HWND hWnd, int nWidth, int nHeight, int nScale) { Destroy(); m_nWidth nWidth; m_nHeight nHeight; m_nScale max(1, min(4, nScale)); // 再往上收益急剧下降 m_nBufW m_nWidth * m_nScale; m_nBufH m_nHeight * m_nScale; HDC hdcScreen GetDC(hWnd); m_hMemDC CreateCompatibleDC(hdcScreen); BITMAPINFO bmi { 0 }; bmi.bmiHeader.biSize sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth m_nBufW; bmi.bmiHeader.biHeight -m_nBufH; // 负数 自上而下行号与屏幕一致 bmi.bmiHeader.biPlanes 1; bmi.bmiHeader.biBitCount 32; bmi.bmiHeader.biCompression BI_RGB; m_hBmp CreateDIBSection(m_hMemDC, bmi, DIB_RGB_COLORS, (void**)m_pBits, NULL, 0); if (!m_hBmp) { DeleteDC(m_hMemDC); m_hMemDC NULL; ReleaseDC(hWnd, hdcScreen); return FALSE; } m_hOldBmp (HBITMAP)SelectObject(m_hMemDC, m_hBmp); SetBkMode(m_hMemDC, TRANSPARENT); m_nPitch m_nBufW * 4; ReleaseDC(hWnd, hdcScreen); return TRUE; }biHeight写成负数是最省事的一步32 位 DIB 默认是自下而上存储正数高度会让你每次算行地址都要(m_nBufH - 1 - y)反一下混着混着就写错。用负数换来自上而下的排布y * pitch x * 4直接就是像素地址。32 位色意味着每个像素 4 字节BI_RGB下 GDI 不解释第 4 个字节。CreateDIBSection拿到的内存是系统清零过的所以你不用自己 memset。还有一点容易踩m_pBits的有效区域到进程退出或DeleteObject(m_hBmp)为止都有效中间千万别把原位图提前删了——SelectObject返回的旧句柄要留到Destroy里再还回去。像素排列顺序是 BGRA不是 RGBAGetRValue对应的写入下标是 2 而不是 0。3.2 Wu 直线把覆盖率算成 alphavoid CSmoothCanvas::DrawLineAA(int x1, int y1, int x2, int y2, COLORREF cr, BYTE alpha) { // 逻辑坐标 - 缓冲坐标加 (scale-1)/2 让线落在像素中心 double x0 (double)x1 * m_nScale (m_nScale - 1) * 0.5; double y0 (double)y1 * m_nScale (m_nScale - 1) * 0.5; double x3 (double)x2 * m_nScale (m_nScale - 1) * 0.5; double y3 (double)y2 * m_nScale (m_nScale - 1) * 0.5; // 陡线转成缓线处理画的时候再把 x/y 换回来 BOOL bSteep fabs(y3 - y0) fabs(x3 - x0); if (bSteep) { std::swap(x0, y0); std::swap(x3, y3); } if (x0 x3) { std::swap(x0, x3); std::swap(y0, y3); } double dx x3 - x0; double dy y3 - y0; double gradient (dx 0.0) ? 1.0 : dy / dx; // 每前进一个 xy 走多远 // 左端点xGap 是端点到像素中心的距离比例 double xEnd floor(x0 0.5); double yEnd y0 gradient * (xEnd - x0); double xGap 1.0 - (x0 0.5 - xEnd); int xPix (int)xEnd; int yPix (int)floor(yEnd); PlotCoverage(bSteep, xPix, yPix, cr, (BYTE)((1.0 - (yEnd - yPix)) * xGap * alpha)); PlotCoverage(bSteep, xPix, yPix 1, cr, (BYTE)((yEnd - yPix) * xGap * alpha)); // 主循环每个 x 列上线覆盖相邻两个像素按小数部分分权 double intery yEnd gradient; for (int x xPix 1; x (int)floor(x3 0.5); x) { int y (int)floor(intery); PlotCoverage(bSteep, x, y, cr, (BYTE)((1.0 - (intery - y)) * alpha)); PlotCoverage(bSteep, x, y 1, cr, (BYTE)((intery - y) * alpha)); intery gradient; } // 右端点与左端点对称源码里复用同一个函数只是 xGap 换成 FPart(x3 0.5) }核心就在intery这个变量上它表示当前 x 列上线条中心的精确 y 值intery - y就是这条线落在下面那个像素里的比例剩下的1 - (intery - y)落在上面那个像素。两个像素按这个比例分颜色权重边缘就自然过渡了。bSteep的处理是为了避免陡线时“一列像素一个点”导致中间出现空隙。判断出斜率绝对值大于 1 就交换 x/y当成缓线算完再换回来PlotCoverage负责这次交换。xGap是端点专用的修正量。如果直接从端点所在的整像素开始画线头会多出半格短线段看起来就像长了尾巴。alpha是整条线的整体不透明度最后跟每个像素的覆盖率相乘用于做半透明叠加。3.3 BlendPixel一次混合里的乘除选择void CSmoothCanvas::BlendPixel(int x, int y, COLORREF cr, BYTE a) { if ((unsigned)x (unsigned)m_nBufW || (unsigned)y (unsigned)m_nBufH || a 0) return; BYTE* p m_pBits (size_t)y * m_nPitch (size_t)x * 4; const int ia 255 - a; // 127 再除 255别直接 8否则每叠一次整体暗一档 p[0] (BYTE)((GetBValue(cr) * a p[0] * ia 127) / 255); p[1] (BYTE)((GetGValue(cr) * a p[1] * ia 127) / 255); p[2] (BYTE)((GetRValue(cr) * a p[2] * ia 127) / 255); p[3] 255; // GDI 不认 alpha留 255 免得后面 AlphaBlend 出鬼 }边界判断用了(unsigned)x (unsigned)m_nBufW这种写法一次比较同时挡住负数和越界比写两个条件快也更不容易漏。返回值直接丢弃因为抗锯齿路径的调用密度太高判断开销会体现出来。8等价于除以 256而权重之和是 255每次混合都会丢掉一点点亮度。单条线看不出来几百条线叠在一起、或者每帧重复混合同一块区域画面就会明显发灰发暗。127再/255是标准的四舍五入补偿编译器会把常量除法优化成乘加不用担心性能。p[3]固定写 255 是个防御性动作。你如果后面想用AlphaBlend把整块缓冲叠到别的 DC 上DIB 里残留的 0 alpha 会让那块区域直接消失排查起来非常费劲。4. 实时性调优帧率卡在 20 帧时先动哪几个参数“实时”这两个字是这份源码的前提。超采样天然是拿性能换画质不设边界地调倍率1080p 全屏重绘很容易掉到个位数帧率。4.1 脏矩形与缓存别每帧重画整屏最有效的一刀是脏矩形。绘制过程中每个图元把自己的包围盒并进m_dirtyEndFrame只把这块区域降采样贴出去。拖动一条线时脏区可能只占屏幕的百分之几省下来的StretchBlt时间非常可观。void CSmoothCanvas::UnionDirty(int x, int y, int cx, int cy) { RECT rc { x, y, x cx, y cy }; // 外扩 1 像素混合会溢出图元边界 InflateRect(rc, 1, 1); ::UnionRect(m_dirty, m_dirty, rc); }外扩 1 像素不是保险起见是必须的抗锯齿混合天然会写到图元包围盒外面那一圈像素上不外扩就会留下一条没被刷新的残影尤其是在背景有图案的时候特别明显。另一个坑是GetPixel/SetPixel。这两个 API 每次调用都要进内核一个 100 万像素的降采样循环用它耗时会比直接读指针慢两个数量级。源码里所有像素访问都走m_pBits y * m_nPitch x * 4这是能用指针就别用 API 的典型场景。4.2 参数怎么定倍率、批处理与内存占用对照表缓冲内存可以直接算W × H × scale² × 4字节。1080p 在 2 倍下是 3840×2160×4 ≈ 33 MB4 倍直接 132 MB再加上贴屏时的临时开销很快就不是小数目。所以源码里把倍率钳在[1, 4]场景建议倍率说明截图标注、静态图编辑2画质与内存的平衡点交互时不卡60fps 连续绘制画板、轨迹12几何图元本来就有 Wu倍率主要给位图用打印/导出34一次性渲染不在乎帧率低配机器或 4K 屏1靠 Wu 撑住线条位图用 HALFTONE 凑还有个容易被忽略的点StretchBlt的HALFTONE模式在缩小一倍以上时才会做真正的均值采样缩小时如果目标尺寸和源尺寸是整数倍关系驱动可能走快速路径反而丢掉细节。所以倍率选 2 或 3 比选 4 在实际观感上差距没有数字那么大但耗时差一倍。测耗时别用GetTickCount精度不够。分段用QueryPerformanceCounter卡在BeginFrame前后和EndFrame前后能立刻看出瓶颈是在图元混合还是贴屏。5. 避坑记录五个最容易翻车的地方5.1 缩放模式不生效越缩越糊现象加了超采样边缘反而比原来更毛躁斜线出现规律性的断点。原因SetStretchBltMode(hdc, HALFTONE)是目标 DC 的状态而且必须配合SetBrushOrgEx重置画刷原点。漏掉后者某些显卡驱动下采样窗口会错位半格等于把邻近像素错开取平均。更麻烦的是远程桌面、虚拟打印机这类环境驱动可能不支持HALFTONE直接退化成COLORONCOLOR——那个模式是直接丢像素锯齿比不做还严重。解决设置完之后用GetStretchBltMode读回来确认退化时干脆自己在 CPU 上做一遍 2×2 或 4×4 的均值降采样代码不长但结果可控。5.2 画面整体发灰、线条越叠越暗现象单条线正常画面上图元一多整体色调偏暗反复重绘同一区域会越来越黑。原因混合公式写成(src * a dst * (255 - a)) 8除以 256 而不是 255每次混合损失约 0.4% 的亮度。抗锯齿一条线要混合两三次几百条线叠加就是肉眼可见的暗。解决统一用(src * a dst * (255 - a) 127) / 255。如果嫌除法慢可以查表或者用(x (x 8) 1) 8这类近似但别图省事直接右移 8 位。5.3 AlphaBlend 上去一块黑、一块透明现象把缓冲用AlphaBlend叠到窗口上本该不透明的地方变成透明或者整块变黑。原因32 位 DIB 的第 4 字节在BI_RGB下 GDI 完全不解释SRCCOPY会忽略它AlphaBlend却会读它。如果你的混合函数没把 alpha 写满 255那块残留的 0 就被当成完全透明。另外AC_SRC_ALPHA要求源图是预乘 alpha没预乘就会偏色。解决不用透明贴图的话BlendPixel里把p[3]恒置 255要用的话混合时就按预乘格式写别再额外乘一次。5.4 文字边缘出现彩色毛刺现象抗锯齿打开后缓冲区里的文字缩小到窗口上边缘出现红蓝色边。原因CLEARTYPE_QUALITY是子像素渲染它假设一个像素由 R/G/B 三个横向子像素组成靠这个做横向三倍分辨率。你再把它缩放到另一个尺寸子像素结构被打乱彩边就出来了。解决参与降采样的文字用ANTIALIASED_QUALITY灰度抗锯齿或者干脆不给文字走超采样路径直接在目标 DC 上按最终坐标绘制。5.5 高 DPI 下线条变粗、位置偏移现象在 150% 缩放比的屏幕上同样的逻辑坐标画出来的线明显更粗位置也偏了。原因画布是按客户区像素尺寸建的但 GDI 在 DPI 感知模式下存在逻辑单位与物理像素的换算两边口径不一致。程序没声明 DPI 感知时系统还会对整个窗口做位图拉伸等于在你的输出上又叠了一次非整数倍缩放。解决manifest 里声明 PerMonitorV2画布尺寸始终用物理像素逻辑坐标乘 DPI 缩放比之后再去画。窗口跨屏拖动时监听WM_DPICHANGED重建画布。6. 二次开发把这套管线接进自己的绘制模块要改哪几处最常见的改造需求是“我原来的代码里到处是dc.LineTo能不能不大改就套上抗锯齿”。能但别指望把CDC整个替换掉。比较省事的做法是抽一个薄接口让原有绘制代码面向接口后端可以在 GDI 直绘和抗锯齿画布之间切换// ICanvas.h —— 只暴露绘图原语不暴露 DIB 细节 class ICanvas { public: virtual ~ICanvas() {} virtual void Begin(HDC hdcTarget, const RECT rcClient) 0; virtual void Line(float x1, float y1, float x2, float y2, COLORREF cr, float w, BYTE a 255) 0; virtual void FillPolygon(const POINT* pts, int n, COLORREF cr) 0; virtual void Bitmap(HBITMAP hSrc, int x, int y, int cx, int cy) 0; virtual void End(const RECT rcDirty) 0; };有了这层调试期把后端切回原生 GDI 做 A/B 对比就是改一行构造的事性能问题也能立刻定位到是抗锯齿开销还是业务逻辑本身慢。线宽参数要注意Wu 直线本身只处理 1 像素宽。要画粗线一种做法是沿法线方向平移画多条间距取 0.7 像素左右靠混合自然叠出实心另一种是先按宽度算出四边形再走多边形填充路径后者在拐角处质量更好但代码量翻倍。我一般先用前者只有做箭头、圆角矩形这类需要精确端点的场景才上后者。验证方法别靠肉眼。拿一张 45 度斜线在 1:1 和 400% 下各截一次图把像素值打出来看灰度过渡是不是连续再用QueryPerformanceCounter记录连续 300 帧的平均耗时和峰值峰值比平均值更能暴露内存分配的问题。这两步做完改动是不是真的有效基本没有争议。还有一个我踩过的坑画布尺寸变化时一定要把整个脏区作废。窗口从 800×600 拖到 1200×900新露出来的那块区域如果没被标记成脏的会一直保留上一帧或者干脆是黑的看起来像是“抗锯齿在某些分辨率下失效了”其实跟抗锯齿一点关系没有。从那以后我每次接 GDI 绘图相关的东西都先把三件事固定写进初始化函数SetStretchBltMode加SetBrushOrgEx的配对、OnEraseBkgnd返回TRUE、以及画布尺寸变化时脏区全量作废。这三行看着不起眼能省掉后面一大半的排查时间。源码已经整理好了先编译跑一遍看效果再照着自己的绘制模块往上套比对着文档空想快得多。希望帮到你。本文还有配套的精品资源点击获取