Win32 GDI绘制这话题放现在看好像有点老古董但实际做桌面工具、工业上位机界面、自绘控件的时候你绕不开它。很多时候产品经理甩过来一个需求要一个实时曲线图、要一个不闪烁的自定义列表、要一个能局部刷新的仪表盘。你用框架自带控件做不出来或者做出来卡成PPT最后还得亲自下场调GDI。这套东西虽然API年迈但逻辑清晰、上手快、可控性强而且很多现代框架的渲染底层思路也从这里演化来的。这篇就把我这些年用Win32 GDI画界面、处理重绘、搞性能优化的经验拆开讲代码都是实际项目里验证过的照着改就能用。1. GDI的核心设计思路先搞懂这几个基础概念1.1 设备上下文(DC)一切的起点GDI里什么事都离不开设备上下文也就是常说的DC。理解它最简单的方式就是把它当成一张虚拟画布所有绘制操作——画线、填色、写字、贴图——都必须在这张画布上进行。这张画布背后可能是屏幕窗口、也可能是内存中的一块位图甚至是一台打印机。你不需要关心它具体怎么工作只要拿到一个DC句柄就能在上面动手。HDC hdc GetDC(hwnd); // 拿到窗口DC // 这里执行各种绘制操作 ReleaseDC(hwnd, hdc); // 用完必须释放这只是最基础的窗口DC。如果在WM_PAINT消息里绘制正确姿势是用BeginPaint拿到DC它跟GetDC有点区别BeginPaint会正确设置裁剪区域让绘制范围只落在无效区域内而且会隐藏插入符绘制完用EndPaint恢复。这两个函数的组合是Windows为消息驱动的重绘机制专门设计的实际写代码的时候不要图省事绕开。case WM_PAINT: { PAINTSTRUCT ps; HDC hdc BeginPaint(hwnd, ps); // 实际绘制代码 EndPaint(hwnd, ps); return 0; }对于内存DC用CreateCompatibleDC创建它一开始只有1x1像素大小必须配合CreateCompatibleBitmap生成一块真正的可绘制内存区域。这块画布就是双缓冲的核心道具。很多人第一次接触GDI时被这些概念绕晕其实记住了DC代表在哪里画GDI对象代表用什么画两者分开理解就顺了。1.2 逻辑坐标与映射模式GDI绘制默认是MM_TEXT映射模式坐标单位就是像素原点在窗口客户区左上角x向右增加、y向下增加。这个模式最直观90%的界面绘制都用它。但某些场景下你会想换映射模式比如画工程图纸、波形图用MM_ISOTROPIC或MM_ANISOTROPIC可以让逻辑单位跟物理尺寸挂钩窗口缩放时图形自动跟着缩放。SetMapMode(hdc, MM_ISOTROPIC); SetWindowExtEx(hdc, 200, 100, NULL); SetViewportExtEx(hdc, 200, -100, NULL); SetViewportOrgEx(hdc, 0, 100, NULL);这段代码的效果是逻辑坐标原点到(200,100)y轴向上为正画出来的图形不需要手动做坐标换算了。我在一个示波器模拟项目里就是这么做的数据坐标直接扔给GDI它自己处理缩放和方向。但要注意MM_ISOTROPIC模式下GDI会强制调整viewport范围让一个逻辑单位x和y对应的物理距离相同如果窗口宽高比例不是1:1图形四周会出现空白区域。这种模式的坑在于逻辑坐标和物理坐标混用容易引起混乱非必要不建议新手直接上手用默认模式加上自己的坐标变换函数反而更可控。2. 一个最小可用的绘制框架从零开始画点东西2.1 窗口过程与WM_PAINT的协作关系Windows绘制体系跟传统画完就扔的思路不同它采用消息驱动加随时可重绘模型。窗口的内容不是永久保存在屏幕上的当窗口被遮挡、拉伸、滚动时系统会向窗口发送WM_PAINT消息你的代码收到消息后重新绘制一遍内容。所以GDI编程的内核逻辑是不只画一次而是准备好随时能画的能力。这意味着绘制代码必须设计成幂等操作——无论调用多少次效果都一样。比如绘制一个自定义控件你不能在WM_PAINT里做状态切换、申请资源、建立缓存这种有副作用的事这些应该放到控件初始化和状态变更的地方。WM_PAINT里只做一件纯粹的事根据当前状态把界面画出来。case WM_PAINT: { PAINTSTRUCT ps; HDC hdc BeginPaint(hwnd, ps); DrawDashboard(hdc, GetWidth(hwnd), GetHeight(hwnd)); // 纯绘制函数 EndPaint(hwnd, ps); return 0; }这种设计保证了系统随时能触发重绘也方便你手动刷新。如果状态变了需要更新界面调用InvalidateRect告诉系统某个区域已经失效系统会在消息循环里生成WM_PAINT。不要直接调用UpdateWindow或SendMessage发WM_PAINT除非你明确知道自己在做什么——比如在调试循环里想立刻看到绘制结果。实际项目中频繁InvalidateRect小区域比一次InvalidateRect大区域更高效这是经验之谈后面性能部分细说。2.2 双缓冲绘制消除闪烁的必备套路界面闪烁是GDI绘制新手遇到的第一个大难题。闪烁的根本原因窗口在擦除背景和绘制前景之间存在空窗期背景被抹成白色或系统默认色而新内容还没画上去眼睛看到的就是不停闪烁。更麻烦的是如果每次重绘都做大量计算窗口会像放幻灯片一样难受。双缓冲方案很直接先在内存里把一帧画好再一次性地BitBlt到屏幕。这样屏幕上不会出现中间状态闪烁自然消失。// 通用双缓冲框架 HDC hdc BeginPaint(hwnd, ps); HDC memDC CreateCompatibleDC(hdc); HBITMAP memBmp CreateCompatibleBitmap(hdc, width, height); HBITMAP oldBmp (HBITMAP)SelectObject(memDC, memBmp); // 在memDC上完成所有绘制 FillRect(memDC, rect, (HBRUSH)GetStockObject(WHITE_BRUSH)); // ... 绘制曲线、文字、图形 ... // 一次性拷贝到窗口 BitBlt(hdc, 0, 0, width, height, memDC, 0, 0, SRCCOPY); SelectObject(memDC, oldBmp); DeleteObject(memBmp); DeleteDC(memDC); EndPaint(hwnd, ps);这里有两个细节值得注意。第一CreateCompatibleBitmap的宽高必须跟客户区一致如果不一致BitBlt时要么拉伸要么裁切容易出边界问题。第二每次WM_PAINT都重新创建和释放内存DC、位图在绘制频率低的情况下完全没问题但如果每秒钟刷新几十帧建议把位图缓存成成员变量避免频繁的创建销毁开销。我在做实时曲线控件时就把memDC和memBmp做成缓存窗口尺寸变了才重建绘制帧率明显提升。除了双缓冲还应该处理WM_ERASEBKGND消息。默认情况下窗口在WM_PAINT之前会擦除背景这个擦除动作是闪烁的一个独立来源。既然双缓冲已经把整个客户区重新画了一遍背景擦除就多余了。case WM_ERASEBKGND: return 1; // 阻止默认擦除背景由双缓冲内容完全覆盖返回1告诉系统背景已经处理好了系统就不会再刷白底。这个技巧配合双缓冲是消除闪烁的完整方案。如果控件只占窗口一部分还有更精细的做法只对控件区域执行BitBlt避免覆盖整个窗口导致其他区域额外重绘。3. 实际开发中最常用的绘制操作3.1 画笔与画刷线条和填充的正确打开方式GDI里画笔Pen决定线条怎么画画刷Brush决定区域怎么填充。很多人刚接触时会迷惑为什么画一个矩形要有两个GDI对象因为矩形边框和内部填充是独立控制的这样设计带来很强的灵活性——边框用虚线内部用斜纹填充这种组合在数据可视化里很常见。画笔创建常用CreatePen或ExtCreatePenHPEN hPen CreatePen(PS_SOLID, 2, RGB(255, 0, 0)); HPEN oldPen (HPEN)SelectObject(hdc, hPen); // 画边框 Rectangle(hdc, 10, 10, 200, 100); SelectObject(hdc, oldPen); DeleteObject(hPen);PS_SOLID是实线还有PS_DASH、PS_DOT等样式。注意PS_DASH和PS_DOT在画笔宽度大于1时会被系统自动转换成实线因为Windows认为粗虚线的视觉意义不大。PS_SOLID配合不同的宽度和颜色已经覆盖90%需求。画刷创建常用CreateSolidBrush或CreateHatchBrushHBRUSH hBrush CreateSolidBrush(RGB(0, 120, 215)); HBRUSH oldBrush (HBRUSH)SelectObject(hdc, hBrush); FillRect(hdc, rect, hBrush); SelectObject(hdc, oldBrush); DeleteObject(hBrush);这里最容易踩的坑是资源管理。GDI对象不吃不喝不自动释放每次CreatePen、CreateBrush都会消耗系统资源池不DeleteObject就会泄漏。Windows对GDI对象数量有硬性限制默认每进程约一万个一旦超过新的绘制调用会静默失败或者单个对象变为唯一无效界面上突然出现画不出来的空白区域。这种bug非常隐蔽因为运行时不会抛异常。后来我把所有GDI对象封装成RAII类构造函数创建、析构函数释放再也没犯过这个错。建议你也这样处理别指望靠记忆力管好这么多句柄。还有一个值得说的对象是StockObject。系统内置了一批基础对象白刷子、黑刷子、灰色刷子、系统字体等。GetStockObject直接拿现成的不需要创建也绝不要DeleteObject。例如重绘背景时用(HBRUSH)GetStockObject(WHITE_BRUSH)非常方便。能系统给的就不用自己创建这也是减少资源管理负担的实用技巧。3.2 文本绘制字体、抗锯齿与清晰度GDI文本绘制涉及字体创建、背景模式设置、文本格式控制几个方面看似简单实际体验差距很大。我总结出来的经验是默认的TextOut能跑通流程但想要好看得自己控制每个参数。字体先用CreateFont或CreateFontIndirect创建然后用SelectObject选入DC。CreateFont参数多为了维护方便通常先填LOGFONT结构体LOGFONT lf {0}; lf.lfHeight -20; // 负数表示字符高度正数表示字符宽度 lf.lfWeight FW_NORMAL; lf.lfCharSet DEFAULT_CHARSET; strcpy(lf.lfFaceName, Microsoft YaHei UI); HFONT hFont CreateFontIndirect(lf); SelectObject(hdc, hFont); SetTextColor(hdc, RGB(51, 51, 51)); SetBkMode(hdc, TRANSPARENT); // 关键文字背景设为透明BkMode是最容易被忽略的选项。默认OPAQUE模式会用当前背景色填充文字背后的矩形区域这会在自绘控件里留下难看的色块。设成TRANSPARENT后文字直接叠加在已有内容上视觉效果自然得多。代价是文字边缘可能不干净因为直接叠加时边缘像素颜色混合可能产生毛边。解决办法是确保背景本身是统一颜色或者干脆用带Alpha通道的绘图API比如AlphaBlend配合32位位图。TextOut和DrawText用哪个也有讲究。TextOut就是无脑地在某坐标开始输出字符串不做格式处理。DrawText则可以做居中、对齐、自动换行、省略号控制RECT rc {20, 20, 220, 60}; DrawText(hdc, 这是一段测试文本, -1, rc, DT_CENTER | DT_VCENTER | DT_WORD_ELLIPSIS);DT_WORD_ELLIPSIS在文本超宽时填充省略号这种效果在列表控件、按钮文字中很实用。还有DT_CALCRECT它可以只计算文本占用的矩形尺寸而不实际绘制用来做控件尺寸自适应非常方便。字体清晰度方面GDI默认的字体光栅化不带ClearType抗锯齿在液晶屏上就感觉发虚。对于窗口绘制在CreateFont时指定lfQuality CLEARTYPE_QUALITY可以有效改善文字边缘。如果做的是自定义控件还可以在创建窗口时注册CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS这些样式来管理重绘行为。字体这块要试不同DPI环境下效果差异很大不能只看设计器里的预览。3.3 位图操作从LoadImage到BitBltGDI位图操作是绘制体系里性能最好的部分因为BitBlt本质上是内存块拷贝速度极快。实际项目经常用位图做缓存的载体——把复杂的静态内容提前画到位图上运行时直接贴出来。加载位图文件用LoadImage最方便HBITMAP hBitmap (HBITMAP)LoadImage(NULL, Limage.bmp, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE);IMPORTANTLoadImage支持bmp、jpg、gif、png部分依赖系统解码器但加载后拿到的是HBITMAP透明度信息在BMP里通常不存在。PNG带Alpha通道需要先用GDI加载或者保持DIB格式才能正确处理透明。我用LoadImage加载PNG的教训是界面边角出现黑色方块就是因为没有处理Alpha通道。后来要么转DIB要么干脆用GDI的Bitmap类统一管理。把位图画到屏幕上用BitBlt或StretchBltBitBlt(hdc, 0, 0, width, height, memDC, 0, 0, SRCCOPY); // 按目标大小缩放 StretchBlt(hdc, 0, 0, dstWidth, dstHeight, memDC, 0, 0, srcWidth, srcHeight, SRCCOPY);BitBlt不做缩放屏幕坐标和位图坐标一一对应速度最快。StretchBlt可以缩放但默认模式会产生锯齿。可以先SetStretchBltMode(hdc, HALFTONE)获得相对平滑的缩放效果代价是速度下降。如果想在运行时动态画出带有渐变、圆角、阴影效果的图形GDI原生能力有限我通常用GDI完成复杂绘制然后渲染到内存DC再用BitBlt贴出来。这种混合用法的性能比纯GDI直接绘制到屏幕高不少窗口的刷新速度和视觉效果都能兼顾。透明贴图也是个高频需求。经典方案使用TransparentBltTransparentBlt(hdc, x, y, width, height, memDC, srcX, srcY, width, height, RGB(255, 0, 255));指定的颜色会被视为透明色不参与绘制。这种方案适合纯色背景的图标。如果需要真正的Alpha混合渐变透明效果就得用AlphaBlend配合32位带Alpha通道的位图了。4. 性能与资源管理的实战经验4.1 资源泄漏GDI对象数量的那条红线GDI句柄泄漏是Win32绘制长期运行的桌面工具最容易遇到的问题。它的可怕之处在于前期无感运行几小时后突然整个界面开始失真——按钮消失、文字变方块、控件背景变黑。原因很简单进程的GDI对象句柄达到万级上限新的分配失败。排查方法并不复杂。在代码里定期加日志输出当前GDI对象数int gdiCount GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS); OutputDebugString((GDI objects: std::to_string(gdiCount)).c_str());如果这个数字持续上升而不是趋于稳定那一定有泄漏点。最常见的泄漏位置就在前面的CreatePen、CreateBrush、CreateFont调用周围——任何SelectObject加入DC的GDI对象在不用之后都必须选回旧对象并DeleteObject自己的对象。我在做仿真项目时就碰到过一次界面每次刷新创建3个画笔、2个画刷、1个字体但忘了DeleteObject。运行20分钟就突破了上限所有的软件渲染全面崩坏。现在还心有余悸所以强烈建议在这些GDI对象外面包一层RAII类。class CGdiObj { public: CGdiObj(HGDIOBJ obj) : m_obj(obj) {} ~CGdiObj() { if (m_obj) DeleteObject(m_obj); } operator HGDIOBJ() const { return m_obj; } private: HGDIOBJ m_obj; };用完的临时对象放在局部作用域里超出作用域自动释放再也不会漏。这条经验怎么强调都不为过分布式系统出了问题还能靠日志查GDI句柄泄漏完全是我只能靠日志加一轮轮代码审查然后被它在生产环境背刺一次才长记性。还有个容易踩的细节BeginPaint拿到的DC必须在EndPaint里释放GetDC拿到的DC必须在ReleaseDC里释放CreateCompatibleDC拿到的DC必须DeleteDC。这三种DC生命周期不一样不能用同一种方式管理。特别是CreateCompatibleDC用完后必须DeleteDC它不占窗口DC的引用但占系统内存句柄。4.2 局部刷新与裁剪把重绘开销降下来GDI性能优化的核心思想不是画得越快而是尽量少画。如果整个窗口只有一个小区域发生了变化却每次都重绘全窗口那再快的函数也顶不住。用InvalidateRect指定无效区域InvalidateRect(hwnd, smallRect, FALSE);FALSE表示不擦除背景TRUE会触发WM_ERASEBKGND擦除背景。在双缓冲场景里不需要系统擦背景传FALSE让WM_PAINT自己处理就行。系统在发送WM_PAINT时会根据无效区域自动设置裁剪区域BeginPaint拿到的DC已经自动带上了裁剪矩形你在这个DC上绘制超出区域的图形会被自动裁掉不会影响外部显示。所以只要在WM_PAINT里正常画就行系统帮你裁剪不必自己再做区域判断。实时刷新的曲线图是个典型的局部刷新场景。你不需要每帧重绘整个窗口只需要把移动的曲线尾部和新增的数据点画出来。做法是保存上一次曲线的位置本次先BitBlt旧位置覆盖掉或者直接把旧区域填充为背景色再在当前位置绘制新线段。这样刷新区域固定在一小条范围内CPU占用大幅下降还能保持60帧稳定运行。我做的实时数据监控界面用了这个方案CPU占用率从12%降到2%左右。另一个加速策略是在绘制前判断可见性。如果控件完全不在窗口可见区域内比如被滚动条滚出视野就别费劲绘制了直接返回。GDI虽然会自动裁剪但裁剪发生在光栅化之后CPU还是白算了一遍。在UpdateWindow或InvalidateRect之后检查一下客户区是否可见节省的是光栅化前的计算开销。4.3 GDI与GDI、Direct2D的选型边界很多人在做自绘界面时纠结到底该用GDI、GDI还是Direct2D。我的经验是能用GDI说清楚的问题别上重武器GDI画不动了再考虑升级。这个画不动包括两种含义——一种是性能瓶颈比如高频率全屏刷新GDI确实撑不住另一种是效果瓶颈比如要画渐变、阴影、圆角、Alpha混合光靠GDI原生功能做起来非常别扭。GDI引入了一些高级绘图能力线性渐变画刷、路径、抗锯齿、Alpha混合、图像格式支持更广。但它也有明显缺点性能比GDI慢对象生命周期管理繁琐笔刷和Pen都要手动释放而且长时间运行在弱GPU环境下会有不稳定性。我的用法是把GDI用在静态效果场景画控件背景的渐变底、圆角边框、不规则的遮罩画一次放到缓存位图里后面的高频刷新仍用GDI的BitBlt显示缓存。这种GDI生成静态效果GDI负责实时合成的混合架构既保住了视觉效果又保住了帧率。Direct2D是硬件加速方案适合复杂动画、大量文字重排、需要GPU参与的图形效果。但Direct2D开发门槛高出不少要管理Device Context、SwapChain、渲染Target还要处理GPU资源丢失的问题。对于一般桌面工具、上位机界面GDI混合GDI方案已经绰绰有余。只有遇到需要高质量实时渲染的游戏面板、高帧率的动态数据可视化时我才会考虑Direct2D。5. 常见问题与排查技巧实录5.1 绘制内容不显示或显示错乱这个问题的表现多样绘制了但屏幕上什么也没有或画面撕裂、交错、局部空白。遇到画了没显示时首先检查DC是否正确。拿错DC或者在错误时机拿DC是最常见的原因。比如使用GetDC拿DC后不ReleaseDC系统相关资源泄漏后续绘制就出错比如在WM_PAINT之外的地方直接画画的内容马上会被下一次WM_PAINT覆盖掉。其次是检查坐标是否越界。GDI对越界绘制不会报错但结果不可预期。比如Rectangle(0,0,100,100)画到只有50x50像素的窗口上你只能看到四分之一的内容其余部分悄悄被裁掉了。用调试器查看坐标或者临时填充一个极端颜色品红色来判断实际绘制区域是否跟预期一致是有效的排查手段。还有种常见情况是Bitmap尺寸和DC尺寸不匹配。双缓冲里创建的CompatibleBitmap宽度高度必须对应客户区大小不一致时BitBlt可能只拷贝部分内容看起来就是画面错位。解决方式是窗口尺寸变化时重建缓存位图case WM_SIZE: { // 释放旧的memBmp重新创建与当前客户区等大的 ReleaseMemoryBuffer(); CreateMemoryBuffer(LOWORD(lParam), HIWORD(lParam)); return 0; }这个处理必须做否则窗口放大后右边和下边就是一片黑的死区。5.2 中文乱码与字体回退问题GDI显示中文乱码或者变成方框多半是字体和字符集不匹配。老代码里用System Font或宋体可能在某些精简系统上缺失系统就自动回退到默认字体默认字体又对应不上中文字符编码就显示出方块。解决方法是统一使用微软雅黑Microsoft YaHei UI这类现代字体并用CreateFontIndirect指定字符集为DEFAULT_CHARSET让系统根据字体名称自动匹配正确的字符集。如果某个字体不存在CreateFontIndirect不会立刻失败而是在实际绘制时回退到默认字体所以最好判断一下字体是否可用。另外手动指定lfCharSet GB2312_CHARSET也可以明确告诉系统用中文字符集但要注意管理好字体多样性避免在不同语言系统上表现不一致。除了字体本身还有一个隐蔽问题Unicode和ANSI字符串混用。GDI绘制函数TextOutA接受ANSI字符串TextOutW接受宽字符字符串。如果你的工程设置了Unicode编译但传进去的是char*出来的就是乱码。这个问题现在比较少见因为新工程默认都是宽字符。但维护老代码时一定要检查工程属性里的字符集设置以及代码里有没有用#ifdef UNICODE做条件编译的地方。5.3 高DPI缩放后界面模糊或错位高DPI是GDI绘制最头疼的问题之一。默认情况下Windows为了兼容老程序会进行DPI虚拟化——系统把窗口缩放后拉伸显示结果就是界面模糊。解决方法有两种。第一种是声明程序支持高DPI在程序启动时主动设置DPI感知SetProcessDPIAware(); // 或 SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE)声明后Windows不再做拉伸你的窗口按照真实DPI坐标工作你必须自己处理所有尺寸——字体高度、控件宽度、坐标位置、位图资源——都要按DPI比例缩放。第二种是根据DPI动态调整绘制参数。最实用的是在WM_DPICHANGED消息中响应根据新DPI重建字体和位图缓存case WM_DPICHANGED: { int dpi HIWORD(wParam); // 按新DPI重建字体、重算布局 RecreateFontsForDpi(dpi); RebuildBitmapCache(dpi); // 建议使用lParam指向的建议矩形来调整窗口大小 SetWindowPos(hwnd, NULL, 0, 0, rect-right - rect-left, rect-bottom - rect-top, SWP_NOZORDER | SWP_NOACTIVATE); return 0; }字体尺寸计算有个经验公式lfHeight -MulDiv(pointSize, dpi, 72)pointSize是设计时使用的磅数dpi是当前系统的DPI值。这样字体在100%和200%缩放下都能保持一致的视觉比例。DPI问题没有一劳永逸的解决方法最好的策略是设计时就把所有尺寸集中管理用相对单位而不是绝对像素保证下次改DPI时只动一处代码。我习惯把控件尺寸、字体大小、间距全部收进一个布局结构体DPI变化时重新计算一遍结构体即可绘制代码完全不用改。结尾写了这么多其实都是从一次次实际踩坑里总结出来的。最开始做GDI绘制时我也觉得这个技术太老许多东西不知道该不该学等真遇到问题才发现越是基础的东西越考验内功。设备上下文、GDI对象管理、重绘机制、裁剪区域这些概念理解透了不管是后来写自绘控件、做数据可视化还是切换到GDI和Direct2D都能更快上手。我个人在实际操作中的体会是GDI这块最好准备一个最小可复现的骨架工程把双缓冲、字体管理、位图缓存这些套路固定下来新项目直接在此基础上改省去反复查资料的时间。如果你在折腾Win32绘制方面遇到了我上面提到的某个问题可以照着排查思路试试八成能解决。以后再看到界面闪烁、文字发虚、GDI泄露心里就有底了。