1. 需求场景与方案取舍：为什么非要用 GDI+ 不可

1.1 哪个项目的需求逼我上了自绘这条路

先说背景。我之前做一个工业设备的管理软件，界面左侧是一整排设备状态卡片，每个卡片上都有三个信号灯式的状态指示：运行、告警、停机。需求刚出来的时候，我第一反应是直接放控件——某某自带的状态灯控件、或者网上找一套红绿灯图片，切换图片就行。

但做到一半，问题来了。设备状态不是只有三种，而是有“未初始化”“运行中”“待机”“告警”“故障停机”“远程锁定”六种状态，而且每种状态的颜色、闪烁方式、是否显示文字说明都不一样。图片方案要么需要准备几十张素材，要么运行时切换图片会非常生硬。至于控件方案，多数第三方控件要么不支持动态改色、要么在缩放窗口时糊成一团。

这时候我决定彻底换思路：不依赖任何现成素材，直接用 VC++ 里的 GDI+ 在窗口上逐像素画出来。这个方案的好处是，信号灯的颜色、高光、边框、文字全部由代码控制，改一个参数，整组灯跟着变。代码写完之后，后续维护只需要调函数参数，不需要再去 Photoshop 里改素材图。

1.2 GDI+ 和普通 GDI 自绘相比赢在哪

有些老派程序员可能会问：自绘为什么不上 GDI？诚然，GDI 画矩形、画圆、填充纯色块也完全没问题，但 GDI 有两个天然痛点：一是没有抗锯齿，画出来的圆形边缘在深色背景上锯齿感特别明显；二是渐变填充、透明度混合、路径柔边这些高级效果做起来非常痛苦，得自己写大段的像素操作。

GDI+ 在这两点上是降维打击。它内置了抗锯齿模式（SmoothingModeAntiAlias）、线性渐变画刷（LinearGradientBrush）、透明度混合（Alpha 混合）、还有StringFormat 文本绘制。最直观的一个体验：画一个带渐变高光的圆，GDI 需要手动计算一圈一圈的环形渐变，GDI+ 只需要定义一个渐变画刷，填充一个图形路径，出来的效果就是平滑自然的立体验。

我把三种方案拉了一张对比表，方便你判断：

提示：如果你的目标平台还停留在 Windows XP 且没有安装过系统更新，GDI+ 需要额外分发动态库；不过现在主流的嵌入式工控上位机基本都是 Win7 起步，系统原生自带，不需要额外部署。

还有一个容易被忽略的成本问题：图片方案短平快，但等到需求变成“告警状态下灯光要由黄变红然后以 1 秒周期闪烁”时，你手上那几十张静态图就完全不够用了。而 GDI+ 方案下，这就只是接口里多一个状态枚举、绘制代码里多一个颜色插值函数的事。

2. 动手前必须想清楚的三个问题：状态模型、坐标系与防闪烁策略

2.1 状态模型：别只盯着“红黄绿”三个灯

很多人一听到信号灯，脑子里就是红黄绿三色，做出来的类也就三个枚举值。但真实项目中，信号灯只是视觉载体，背后往往是复杂的业务状态。我这次的项目最终定义了六种状态：

• ST_OFF：未上电/未初始化，灰色半透明
• ST_RUNNING：运行中，绿色常亮
• ST_STANDBY：待机，黄色常亮
• ST_WARNING：参数越限告警，黄色闪烁
• ST_ALARM：严重故障，红色闪烁
• ST_LOCKED：远程锁定，红色常亮但亮度压低（避免与告警混淆）

这里有个设计心得：状态的值域一定要比现在需要的大。宁可先预留几个空状态枚举位，也不要等上线后才发现还要加一种“维护中”状态，然后到处改 switch-case。我一开始只定义了三个状态，后来需求方加了一个“远程锁定”，我不得不把所有关联的状态判断点翻出来逐个排查，非常被动。

除此之外，我建议把“灯色”和“灯效”拆成两个维度，而不是混在一个枚举里。比如黄色闪烁可以表达待机，也可以表达参数越限；红色常亮和红色闪烁的含义也完全不同。将颜色与闪烁方式解耦后，绘制代码逻辑会简单得多：颜色决定画什么，效果决定怎么画。

2.2 绘制坐标系：所有元素都用 0~1 相对坐标布局

第二件要想清楚的事是坐标系设计。傻瓜做法是直接用控件当前的像素宽高去计算圆形的圆心坐标和半径，比如在 31×31 的控件里画一个半径 12 的圆。这样做的直接后果是：控件一旦被调整尺寸，所有元素要么溢出边界，要么间距失衡。

用相对坐标就稳得多。我设定了一个 0~1 的虚拟坐标系，之后所有的圆盘、高光、文字框位置都以这个坐标系里的归一化值表示，真正绘制时再乘以控件实际宽高。这个习惯救过我很多次——客户要求在 4K 分辨率屏幕上放大界面，窗口整体从 800×600 变成 1920×1080，信号灯控件被拉伸了三倍，但因为绘制代码跑在相对坐标系下，最终画面依旧比例协调，没有出现大圆套小圈这类畸形比例。

相对坐标还有一个额外的好处：高分辨率屏幕下依然清晰。GDI+ 是矢量绘制，圆边是否平滑取决于抗锯齿级别，而不是像素密度。只要你在缩放时调用 Control 的尺寸变化事件让它重绘，画面就会在任意尺寸下保持同样比例。

2.3 双缓冲与透明刷新：让画面不闪不黑的关键

UI 自绘最大的坑之一就是闪烁。闪烁的根源是：系统先擦除背景（WM_ERASEBKGND 触发，背景被刷成默认色），然后你的绘制代码才逐像素画出内容。这个“先擦后画”的过程在屏幕上快速反复执行时，人眼就会看到闪烁。

GDI+ 环境下，最稳妥的做法是双缓冲：先创建一块内存中的位图，把所有元素画在位图上，最后一次性 BitBlt 或 DrawImage 到屏幕上。但 GDI+ 的双缓冲有一个细节：很多人用的是 CreateCompatibleDC 和 CreateCompatibleBitmap 这两件套，在 GDI+ 里画之前又 GetDC 又 SelectObject，最后发现绘制的坐标全错了、颜色也不对。

我实际用下来最省心的是直接在 GDI+ 里创建 Bitmap 作为缓冲画布：

Bitmap bmp(drawWidth, drawHeight, PixelFormat32bppARGB); Graphics gBuf(&bmp); gBuf.SetSmoothingMode(SmoothingModeAntiAlias); // 所有绘制操作都丢给 gBuf Graphics gTarget(hdc); gTarget.DrawImage(&bmp, 0, 0, drawWidth, drawHeight);

这个方案的代码量更少，而且 32 位 ARGB 位图天然支持透明通道，可以保留圆角之外的透明区域。另外一定要在处理 WM_ERASEBKGND 时直接返回 TRUE，彻底关掉系统擦背景动作，否则双缓冲也会白做——系统擦背景的那一下闪烁依然存在。

注意：绘制结束后记得将所有 GDI+ 对象 Dispose，尤其是画笔（Pen）、画刷（Brush）、渐变对象，否则长时间运行后句柄泄漏，界面会越用越卡。GDI+ 的托管感知不强，这一点全靠自己自觉。

3. 实操落地：信号灯控件从无到有的编码过程

3.1 三步初始化 GDI+：忘了这步画面直接黑屏

GDI+ 不是系统默认启用的，使用前必须先调用 GdiplusStartup 完成初始化。这个步骤经常被新手漏掉，漏掉后的表现非常统一：窗口能创建、消息能响应，但绘制区域一片漆黑或者什么也不显示，调试时又不会报错，非常气人。

初始化顺序分三步：第一步包含头文件并链接库；第二步定义 GdiplusStartupInput 结构体；第三步调用 GdiplusStartup 获取令牌。这个令牌（ULONG_PTR 类型）必须在整个 GDI+ 生命周期内保存，最简单的做法是做成单例的 RAII 类，构造时初始化、析构时关闭。

#include <windows.h> #include <gdiplus.h> #pragma comment(lib, "gdiplus.lib") class GdiPlusModule { private: ULONG_PTR m_gdiplusToken; public: GdiPlusModule() : m_gdiplusToken(0) { Gdiplus::GdiplusStartupInput input; input.GdiplusVersion = 1; input.DebugEventCallback = NULL; input.SuppressBackgroundThread = FALSE; input.SuppressExternalCodecs = FALSE; Gdiplus::GdiplusStartup(&m_gdiplusToken, &input, NULL); } ~GdiPlusModule() { if (m_gdiplusToken) { Gdiplus::GdiplusShutdown(m_gdiplusToken); } } };

在我实际开发中，遇到过因为初始化顺序错误导致画面错乱的情况——控件窗口先创建了，主程序里 GdiplusStartup 才调用，结果绘制时部分渐变效果不稳定。所以建议在程序入口（比如 CWinApp::InitInstance）里最先做这件事，确保任何窗口创建之前 GDI+ 环境已经就绪。

3.2 控件基类与注册：一个 CWnd 足够

信号灯控件不承载交互逻辑，不需要高大上的 MFC 控件基类，一个 CWnd 子类就够了。关键点在 PreCreateWindow 里注册窗口类时，要给它一个独立的类名并指定合适的样式，否则会出现刷新区域异常、背景怪色等问题。

class CSignalLight : public CWnd { public: enum SignalState { ST_OFF = 0, ST_RUNNING, ST_STANDBY, ST_WARNING, ST_ALARM, ST_LOCKED }; BOOL Create(CWnd* parent, const CRect& rc, UINT id) { static CString className; if (className.IsEmpty()) { className = _T("MY_SIGNAL_LIGHT_CLASS"); WNDCLASS wc = {0}; wc.style = CS_HREDRAW | CS_VREDRAW; // 尺寸变化自动重绘 wc.lpfnWndProc = ::DefWindowProc; wc.hInstance = AfxGetInstanceHandle(); wc.lpszClassName = className; AfxRegisterClass(&wc); } return CWnd::Create(className, _T(""), WS_CHILD | WS_VISIBLE, rc, parent, id); } virtual void OnPaint() { CPaintDC dc(this); OnDrawSignalLight(dc); } virtual BOOL OnEraseBkgnd(CDC*) { return TRUE; // 禁用背景擦除，配合双缓冲 } protected: SignalState m_state = ST_OFF; void OnDrawSignalLight(CDC& dc); };

3.3 核心绘制函数拆解：底色、高光、灯体、文字

整个控件绘制流程，拆开看是四个图层：外圈底座（阴影与凸缘）、灯体（色彩主区域）、高光（模拟玻璃球体折射）、状态文字。四个图层按顺序一层层叠上去，画面就有立体感了。

先看最核心的上色逻辑。我为了让灯体四层颜色之间的过渡更自然，做了一个简单的颜色插值函数，用的是 ARGB 通道分离的方式：

COLORREF InterpolateColor(COLORREF c1, COLORREF c2, double t) { int a1 = (c1 >> 24) & 0xFF, r1 = (c1 >> 16) & 0xFF; int g1 = (c1 >> 8) & 0xFF, b1 = c1 & 0xFF; int a2 = (c2 >> 24) & 0xFF, r2 = (c2 >> 16) & 0xFF; int g2 = (c2 >> 8) & 0xFF, b2 = c2 & 0xFF; return RGB( (int)(r1 + (r2 - r1) * t), (int)(g1 + (g2 - g1) * t), (int)(b1 + (b2 - b1) * t) ) | ((int)(a1 + (a2 - a1) * t) << 24); }

上色时的核心代码我贴一段关键部分，注意里面每个元素都使用归一化坐标：

void CSignalLight::OnDrawSignalLight(CDC& dc) { CRect rc; GetClientRect(&rc); int w = rc.Width(), h = rc.Height(); // 1. 用双缓冲位图作为画布 Bitmap bmp(w, h, PixelFormat32bppARGB); Graphics g(&bmp); g.SetSmoothingMode(SmoothingModeAntiAlias); g.SetPixelOffsetMode(PixelOffsetModeHalf); // 2. 计算圆盘核心参数（归一化坐标） float cx = w / 2.0f; float cy = h / 2.0f; float baseRadius = (float)(min(w, h) * 0.38f); // 外盘半径 float lampRadius = baseRadius * 0.78f; // 灯体半径 // 3. 外圈底座（深灰色圆环 + 内阴影） SolidBrush darkBrush(Color(255, 60, 60, 60)); g.FillEllipse(&darkBrush, cx - baseRadius, cy - baseRadius, baseRadius * 2, baseRadius * 2); // 4. 灯体主体（根据状态取色） COLORREF lampColor = GetStateColor(m_state); Color baseColor( GetAValue(lampColor) , GetRValue(lampColor), GetGValue(lampColor), GetBValue(lampColor) ); SolidBrush lampBrush(baseColor); g.FillEllipse(&lampBrush, cx - lampRadius, cy - lampRadius, lampRadius * 2, lampRadius * 2); // 5. 高光（右上角的白色渐变椭圆，模拟玻璃反光） GraphicsPath hlPath; float hlW = lampRadius * 1.0f, hlH = lampRadius * 0.6f; float hlX = cx - lampRadius * 0.55f; float hlY = cy - lampRadius * 0.55f; hlPath.AddEllipse(hlX, hlY, hlW, hlH); PathGradientBrush hlBrush(&hlPath); hlBrush.SetCenterColor(Color(180, 255, 255, 255)); hlBrush.SetSurroundColors(Color(0, 255, 255, 255)); g.FillPath(&hlBrush, &hlPath); // 6. 状态文字（如需显示） // ... // 7. 一次性绘制到窗口 Graphics gScreen(dc.GetSafeHdc()); gScreen.DrawImage(&bmp, 0, 0, w, h); }

关于高光，补充一个经验：很多人画高光喜欢直接用实心白色椭圆往上面一盖，结果画面像贴了一张白纸，非常假。真正模拟玻璃球体的做法是用 PathGradientBrush，让高光中心的颜色从半透明白（Alpha 约 180）向边缘渐变到完全透明（Alpha 0），只有一个方向性柔边，这才能营造出“光从右上方打到球体表面”的立体感。

3.4 坐标换算与高光比例的计算方法

有人会问上面这些比例数字（0.38、0.78、0.55）是怎么来的，其实是我在各种尺寸下反复试出来的经验值，你可以直接抄：

• 底座半径占控件最短边的 38%，这样四周留白足够，不会贴边
• 灯体半径占底座的 78%，留出外侧一条 22% 宽度的深色环，模拟灯壳厚度
• 高光椭圆宽度约为灯体直径的 70% 多一点，高度约为直径的 42%，中心落在灯体右上方的黄金位置

如果你追求更精细的自适应效果，可以把这些比例值提取成成员变量，然后在 SetSize 或 OnSize 里统一计算。我用过一段时间后，觉得静态比例就已足够，动态比例反而容易在不同屏幕尺寸下出现形变。

有一件小事千万别忽略：GDI+ 的 Graphics 默认有 1 像素的坐标偏移，绘制 1 像素宽的线条时如果坐标是整数，线条会渲染在相邻两个像素之间，看起来发虚。解决办法是设置 PixelOffsetModeHalf，或者给坐标多加 0.5f。这是个非常典型的“看起来没毛病但总像蒙了层雾”的坑。

4. 状态切换与动画插值：让信号灯学会“呼吸”

4.1 定时器驱动的颜色插值

状态切换如果只是瞬间变颜色，会显得非常廉价。我想要的效果是：旧颜色平滑过渡到新颜色，这个过程大约持续 200~300 毫秒。实现方式是引入一个 30ms 定时器，每次触发时计算当前颜色到目标颜色的插值比例，重绘一次。

void CSignalLight::AnimateTo(COLORREF targetColor) { m_targetColor = targetColor; m_animStartTime = GetTickCount64(); m_animDuration = 240; // 毫秒 SetTimer(ANIM_TIMER_ID, 30, NULL); } void CSignalLight::OnTimer(UINT_PTR id) { if (id != ANIM_TIMER_ID) return; DWORD64 now = GetTickCount64(); double t = (double)(now - m_animStartTime) / m_animDuration; if (t >= 1.0) { t = 1.0; KillTimer(ANIM_TIMER_ID); } COLORREF curColor = InterpolateColor(m_currentColor, m_targetColor, t); m_currentColor = curColor; Invalidate(FALSE); }

插值用的比例 t 如果直接是线性值，动效会有一点生硬，头尾都不带缓动。我建议加一个缓动函数，比如先快后慢的平滑过渡：

double SmoothStep(double t) { return t * t * (3 - 2 * t); }

把上面的 t 替换成 SmoothStep(t) 之后，颜色切换在视觉上会自然很多。类似的技巧也可以用在闪烁渐变上——闪烁过程中透明度的建立和消退都采用这种缓动曲线，灯光的呼吸感一下就出来了。

4.2 闪烁与常亮组合的几种实战用法

几个状态映射里，闪烁其实有讲究。简单做法是每 500ms 把灯色在“目标色”和“暗色”之间来回切换，但这种生硬的两态切换在视觉上很突兀。

我采用的是正弦波形的亮度变化。用一个累计相位，让 Alpha 值按正弦函数周期性起伏，闪烁不再是跳变，而是一明一暗的自然呼吸：

void CSignalLight::UpdateFlashingState() { if (!m_isFlashing) return; double phase = (double)(GetTickCount64() % 1000) / 1000.0; // 0~1 double brightness = 0.5 + 0.5 * sin(phase * 2 * 3.1415926); // 用 brightness 调整灯光 Alpha/明暗程度 Invalidate(FALSE); }

在工控界面里，告警灯如果只是“红色常亮”，人的注意力很快就会习惯化，反而捕捉不到变化。闪烁频率 1~2Hz 是眼动敏感性比较高的区间，太慢显得呆滞，太快给人压迫感。我实测下来，闪烁周期设定在 800~1000ms 比较舒服。

4.3 对外接口设计：SetState 之后内部发生了什么

接口设计上，外界只需要调用一个 SetState，所有内部逻辑自动完成。好处是业务代码不用关心绘制细节，将来替换成别的视觉方案也只改这个类内部。

void CSignalLight::SetState(SignalState state) { if (m_state == state) return; m_state = state; // 根据状态确定颜色与闪烁需求 COLORREF target; bool flash = false; switch (state) { case ST_OFF: target = RGB(120, 120, 120); flash = false; break; case ST_RUNNING: target = RGB(0, 200, 80); flash = false; break; case ST_STANDBY: target = RGB(255, 200, 0); flash = false; break; case ST_WARNING: target = RGB(255, 160, 0); flash = true; break; case ST_ALARM: target = RGB(230, 30, 30); flash = true; break; case ST_LOCKED: target = RGB(160, 20, 20); flash = false; break; } m_isFlashing = flash; AnimateTo(target); if (m_isFlashing) { SetTimer(FLASH_TIMER_ID, 100, NULL); // 10Hz 刷新闪烁相位 } else { KillTimer(FLASH_TIMER_ID); } }

这段代码在 OnTimer 里同时处理动画和闪烁相位，但在实践中要注意：当动画和闪烁同时发生时（比如从绿色运行态切到红色告警态），先让颜色插值动画跑完再启动闪烁节奏，否则闪烁会和颜色渐变打架，画面看起来像抽搐。控制方法很简单：AnimateTo 结束后再设置闪烁标志。

5. 实战中踩过的坑：GDI+ 绘图的常见问题速查

5.1 初始化与生命周期相关

只调了 GdiplusStartup 忘了匹配 Shutdown。桌面软件可能看不出来，但你要是把这个控件塞进一个频繁创建销毁的窗口里，每次创建都初始化、销毁时却不关闭，句柄和内存会持续累积，程序跑七八个小时后界面越来越卡，最后直接黑屏。

初始化顺序问题。GDI+ 环境要在第一个 GDI+ 控件创建前就绪。有人把 GdiplusStartup 放在某个模块的静态构造函数里，结果模块加载顺序和控件创建顺序冲突，绘制函数进入时 GDI+ 还没准备好，导致绘制静默失败。建议初始化放在主程序最早执行的位置。

多线程绘制。GDI+ 的 Graphics 对象基本上只能由创建它的线程使用，跨线程释放或者绘制会崩溃或者产生随机花屏。如果你自己做了一个后台工作线程来刷新信号灯，切记最终 Invalidate 时 PostMessage 到 UI 线程，不要在后台线程里直接创建 Graphics 丢到窗口。

5.2 绘制性能与质量

5.3 消息处理与窗口行为

WM_ERASEBKGND 的处理。这一步不能漏，否则即使做了双缓冲，切换状态时仍能看到瞬间的白色闪动。在 MFC 里面就是重写 OnEraseBkgnd 且返回 TRUE。

控件尺寸变为 0 或负数。客户如果把窗口缩到极小，或者布局代码设置了一个空的矩形，绘制函数里计算坐标会得到负数半径，FillEllipse 的行为就会异常。稳妥做法是绘制函数入口判断宽高是否小于某个阈值（比如 8 像素），直接跳过绘制。

DLL 版本冲突。如果软件里还引用了其他依赖 GDI+ 的第三方库，可能因为系统 GDI+ 版本差异产生兼容问题。我遇到过一次装在某台老机器上，信号灯控件偶尔画出来是空心的，排查许久发现是该机器 GDI+ 版本过旧，对 PathGradientBrush 的 SurrooundColors 支持不完整。解决方式是升级系统补丁，或者在高版本不可用时退化为两段式渐变。

5.4 一个容易忽略的透明窗口环境

如果你的信号灯不是放在普通对话框上，而是叠加在透明或分层窗口（WS_EX_LAYERED）上，直接 GDI+ 绘制会出现黑色底块。这是因为分层窗口更新需要指定透明色键或者使用 UpdateLayeredWindow。我试过在分层窗口里放自绘控件，最后是改成用 UpdateLayeredWindow 整幅更新整个窗口内容，而不是让控件单独自绘，才把黑色底块问题解决。如果业务场景不是特别需要分层窗口，尽量别往这个方向走。

6. 写在最后：一点私货与扩展建议

代码能跑是一回事，跑得稳是另一回事。这里想分享我后来在这个控件上面做的一些扩展，也算给你留几条后续方向。

第一个扩展是“点击反馈”。我把信号灯控件处理了 WM_LBUTTONDOWN，按下时高光位置瞬间改变、亮度短暂降低，松开恢复，用来模拟物理按钮的按压感。这在“手动确认告警”这类交互里特别有用，用户会感觉自己在操作一个真实存在的灯而不是一张图片。

第二个扩展是“状态文字气泡”。只画灯不加文字，长时间盯屏容易混淆；但直接在灯旁边画文字又会破坏灯的圆润感。我后来实现了一个悬浮文本层，鼠标悬停 500ms 后浮出一个小气泡，显示状态名称和最近一次切换的时间。这个功能做起来不难，但用户反馈特别好。

第三个扩展是“亮度曲线预置”。对闪烁的亮度变化曲线做成了可配置项——正弦、三角波、矩形波、随机跳变。告警时随机跳变比正弦更刺眼，待机时三角波比正弦更有节奏感。一条曲线函数不到十行代码，换来的是各种业务场景下都能调到合适的警示强度。

最后再说一句真心话：GDI+ 自绘确实比贴图方案初期多花点时间，但一旦把绘制核心写完，后续任何需求变动都是在已有框架上做加法，而且整个过程完全不依赖美术资源。这种“代码即素材”的开发方式，在需求频繁变化的中小型项目里，是最稳妥、后遗症最少的路线。

如果你也在做类似的设备监控界面，建议从一个小控件开始试，跑通完整链路之后，就再也回不去贴图方案了。