MFC ChartCtrl实时波形显示源码：环形缓冲与定时器刷新

简介：这份源码工程面向需要在 VC++/MFC 环境下实现动态波形显示的中初级开发者，以 ChartCtrl 图表控件为核心，演示折线波形从控件初始化、数据组织到定时刷新与鼠标交互的完整链路。压缩包内共 80 个文件，以 36 个 .h 头文件与 26 个 .cpp 源文件为主体，另有 4 个 .inl 内联实现，以及 .sln 解决方案、.vcxproj 工程配置、.rc 对话框资源与 ico 图标等配套文件，整体约 41.86MB，可用 Visual Studio 直接打开并编译对照。代码按对话框类初始化、坐标轴范围设定、数据点追加、定时器驱动刷新、点击与缩放事件响应等环节分层组织，可据此理解 AddSeries、SetXAxis/SetYAxis 一类接口的调用时机，并参考其中的图表配色、网格线与图例调整思路。目前已有 3853 人学习下载。

1. 先别急着自绘 GDI：一份 ChartCtrl 波形显示实例源码能省下的两周

很多做 MFC 上位机的人在“画波形”这一步被卡住：用OnPaint里徒手MoveTo/LineTo，一开始几百个点还行，点数一多、窗口一拉伸、要加缩放和平移，代码立刻失控。这份 ChartCtrl 波形显示实例源码解决的正是这个问题——它把坐标轴、曲线序列、缩放平移、数据刷新这些重复劳动封装成一个可以直接子类化的控件，你只要负责把数据喂进去。它适合三类人：正在做采集类毕设、需要交一个能跑的波形界面的学生；要给设备做监控面板、又不想引入庞大绘图框架的工程师；以及课程设计里被要求“必须用 MFC + 实时曲线”的人。这一章先说清为什么要换思路，后面几章把这套源码怎么集成、怎么刷新、怎么验收一层层拆开。

2. 场景与选型：三类波形需求怎么匹配 ChartCtrl 的类结构

波形显示看起来是同一个需求，实际差别很大。有人要的是采集卡每秒几千点连续刷新的实时滚动窗，有人要的是把一段历史数据事后回放，有人只是把一组实验数据画成静态折线贴进报告。这三种需求对刷新频率、缓冲方式、交互能力的要求完全不同，先分清属于哪一类，再决定控件怎么用，能省掉后面大量的返工。

2.1 三类场景的刷新节奏与硬指标

第一类是实时采集显示，典型场景是串口或网口收数据，采样率 100 Hz 到 2 kHz，界面上永远只保留最近几秒到几十秒的窗口，曲线向右滚动。这类需求的关键指标是单帧绘制耗时，通常要压到 16 ms 以内，否则界面会明显发滞，鼠标拖窗口都会卡。

第二类是事后回放，一整段数据可能几十万个点，用户点“加载”之后看整体趋势，然后局部放大看细节。这类需求拼的是首次装载速度和内存占用，不是帧率，所以可以用一次性AddPoints全量灌入，配合控件的缩放功能。

第三类是静态曲线，数据在几百到几千点，画完就不动，通常出现在实验报告、出厂检测记录里。这类最简单，也最容易被过度设计——很多人给静态曲线套了一套定时器刷新逻辑，反而引入了不必要的复杂度。

判定方法很简单：数据是不是持续产生、用户是否需要看到“最新值”。是，就走实时路径；否，走回放路径。这两条路径在同一个工程里可以共存，但刷新函数必须分开，不要用一个函数兼顾两种节奏。

2.2 自绘 GDI、ChartCtrl 与通用图表控件的边界

选型这块我踩过的坑最多。自绘看起来最自由，但坐标轴刻度算法、标签避让、抗锯齿、缩放平移全要自己写，一个合格的波形控件光刻度自动选择就要两三百行。通用图表框架（那些跨平台的大库）功能全，但塞进一个纯 MFC 对话框工程往往要拖进一堆依赖，编译配置先耗半天。

ChartCtrl 的位置刚好在中间：它是原生 MFC 控件，以源码形式参与编译，没有外部 DLL 依赖；提供标准轴、线序列、点序列、网格、图例；缩放平移是控件内置的。代价是它不追求花哨效果，样式偏朴素，如果你的需求里要做渐变填充、动画过渡这类视觉效果，它给不了。下面这张表是我在实际选型时用的判断依据：

结论是：只要你画的是“X-Y 折线/散点 + 坐标轴 + 偶尔缩放”，ChartCtrl 的性价比最高；如果你的图形是仪表盘、热力图、极坐标玫瑰图，那它不合适，别硬套。

2.3 源码里的三层结构：控件、坐标轴、序列

拿到这套实例源码，先别急着改代码，花十分钟理清类之间的关系，后面所有问题都能定位。它的组织方式是典型的三层：

三者是“控件持有轴和序列”的聚合关系：一个控件可以有上下左右四个轴，可以挂多条曲线，每条曲线自己管自己的点。理解这一点很关键——很多新手把数据往控件上塞，找不到对应方法，实际上是塞错了层，数据必须交给序列对象。

另外要留意序列的“排序模式”。线序列默认会按 X 值排序后再绘制，这在静态数据下没问题，但在实时滚动场景里，每帧都排序一次是纯浪费，而且当你的 X 值是递增的时间戳时排序结果完全一样。实例源码里通常会用SetSeriesOrdering把排序关掉，这个开关是后面性能优化的第一个抓手，先记住。

3. 工程集成：把控件挂到对话框上的三条路与初始化脚本

集成这一步决定你后面调试顺不顺。三种挂载方式各有适用面，选错了不会立刻报错，但会在某个环节让你怀疑人生，比如控件位置永远对不上，或者窗口一缩放控件就消失。

3.1 三种挂载方式的取舍

方式一：对话框资源里放 Custom Control。在资源编辑器拖一个 Custom Control，Class 填控件的窗口类名（这套源码里注册的类名一般就是ChartCtrl），ID 设为IDC_CHART。对应的 rc 片段大致是：

// 对话框资源中的一行，注意 Class 必须是控件注册的窗口类名 CONTROL "",IDC_CHART,"ChartCtrl",WS_TABSTOP,7,7,320,180

然后在对话框类里声明一个CChartCtrl成员，OnInitDialog里子类化：

// 头文件 #include "ChartCtrl.h" class CWaveDlg : public CDialogEx { // ... CChartCtrl m_Chart; // 控件成员，随对话框一起构造析构 }; BOOL CWaveDlg::OnInitDialog() { CDialogEx::OnInitDialog(); // 把资源里的占位控件替换成真正的图表控件 if (!m_Chart.SubclassDlgItem(IDC_CHART, this)) { AfxMessageBox(_T("图表控件子类化失败，请检查 Class 名是否正确")); return FALSE; } InitChart(); // 轴与序列的初始化，见 3.2 return TRUE; }

这种方式的优点是控件位置、大小全部由资源编辑器管，改布局不用动代码；缺点是 Class 名写错时资源编辑器不报错，运行时只看到一个灰色空框。

方式二：代码里动态 Create。不占资源，用Create指定矩形。适合控件要跟着某个布局算法走，或者数量不定的场景：

// 在对话框的 OnCreate 或 OnInitDialog 中动态创建 CRect rcClient; GetClientRect(&rcClient); rcClient.DeflateRect(10, 10, 10, 40); // 四周留白，底部给按钮让位 if (!m_Chart.Create(rcClient, this, IDC_CHART)) { AfxMessageBox(_T("图表控件创建失败")); return FALSE; }

注意Create的参数顺序在不同版本里可能是(矩形, 父窗口, ID)也可能是(父窗口, 矩形, ID)，打开头文件看声明一眼就能确认，别照抄网上的写法硬编译。动态创建的控件不参与对话框的自动布局，需要在OnSize里自己MoveWindow。

方式三：SubclassDlgItem加占位静态框。先用一个 Static 控件占位，再子类化成图表控件。这种做法在老工程里常见，好处是资源编辑器里能直观看到占位区域，坏处是 Static 控件默认的样式可能会干扰，需要确认子类化后样式被覆盖。

我的建议是：毕设和课程设计用方式一，省事；需要按窗口自适应、控件数量可变的工程用方式二，配合OnSize做布局。

3.2 轴与序列的初始化：一次配好，后面只管喂点

控件建好之后，第一件事是建轴、建序列。这一步容易写漏，比如只建了底部轴没建左侧轴，结果曲线画出来了但没有纵坐标刻度，看起来像坏了。标准配置如下：

void CWaveDlg::InitChart() { // 1) 外观：背景与边框 m_Chart.SetBackColor(RGB(255, 255, 255)); m_Chart.SetBorderVisible(true); // 2) 轴：底部 X 轴 + 左侧 Y 轴，量程自动 CChartAxis* pBottom = m_Chart.CreateStandardAxis(CChartCtrl::BottomAxis); CChartAxis* pLeft = m_Chart.CreateStandardAxis(CChartCtrl::LeftAxis); if (pBottom != nullptr) { pBottom->SetAutomatic(true); // 自动量程，随数据伸缩 pBottom->SetDiscrete(false); // 连续轴，适合时间/电压 } if (pLeft != nullptr) { pLeft->SetAutomatic(true); pLeft->SetMinMax(-1.0, 1.0); // 先给个默认范围，避免空数据时刻度跳到 0 } // 3) 序列：一条折线 CChartLineSerie* pSerie = m_Chart.CreateLineSerie(); if (pSerie != nullptr) { pSerie->SetColor(RGB(0, 120, 215)); pSerie->SetWidth(2); pSerie->SetSeriesOrdering(poNoOrdering); // 关键：关闭 X 排序 } // 4) 交互：允许鼠标框选缩放与拖动平移 m_Chart.EnableZoom(true); m_Chart.EnablePan(true); m_Chart.RefreshCtrl(); }

几个参数值得单独解释。SetAutomatic(true)打开自动量程，控件会根据当前数据的最小/最大值调整坐标轴范围，实时波形里通常要开；但如果你希望纵轴固定成 ±5V 便于对比，就改成SetAutomatic(false)再用SetMinMax，否则数据一小，曲线会被自动放大到满屏，看着像噪声。SetSeriesOrdering(poNoOrdering)是性能相关的开关，关掉排序之后数据按你给的顺序连成线，实时场景必须这么设置。EnableZoom/EnablePan打开后，用户在图上左键拖框可以放大，右键或按住中键拖可以平移——这两个功能演示时很加分，但要注意和业务用鼠标操作的冲突，比如你的窗口里画图区还要支持点击取点，就要在鼠标消息里做区域判断。

3.3 数据灌入：一次性、增量与覆盖三种方式

序列的数据接口主要有三类用法，选错会带来麻烦。

一次性灌入适合静态曲线和回放，直接把数组丢进去：

// 静态数据：整段一次性写入，适合回放和实验报告曲线 std::vector<double> xs(nCount), ys(nCount); // ... 填充数据 ... pSerie->AddPoints(xs.data(), ys.data(), (unsigned)nCount);

增量追加适合低频数据（比如每秒几个点），每次来新点就AddPoints一个点。但高频场景下千万别这么用：每次追加都可能触发内部的点数组扩容与下标重算，1000 Hz 下就是每秒 1000 次扩容检查，卡顿是必然的。

覆盖更新是实时波形的最优解：数据先在内存缓冲里滚动，每帧用SetPoints从指定下标开始整体覆盖一段点。这样控件的点数组长度恒定，不扩容，绘制路径也稳定。下一章就按这个思路把缓冲和刷新搭起来，这是整套源码里最值得照搬的部分。

4. 实时刷新：环形缓冲、定时器与绘制开销的三个开关

实时波形卡不卡，九成取决于数据缓冲怎么设计，控件本身只占一小部分。很多人的做法是每次来新点就清空序列再全量重加，几百个点还好，上千点就开始闪；再叠加自动量程的重算，就变成了肉眼可见的掉帧。

4.1 缓冲设计：定长环形数组 + 固定窗口

核心思路是“控件里永远只有窗口长度的点”。假设你要显示最近 5 秒、采样率 200 Hz，那窗口就是 1000 点。开一个长度 1000 的环形数组，新数据覆盖最旧的位置，同时记录写指针。绘制时不是把环形数组原样丢进去（那样时间顺序会被打断，曲线会出现一条横跨全图的回折线），而是按写指针把它“展开”成两段连续拷贝到一个线性缓冲，再交给控件。

// 定长环形缓冲：容量固定，写入不回绕顺序，读到线性缓冲再绘制 class CRingBuffer { public: explicit CRingBuffer(size_t nCapacity) : m_nCapacity(nCapacity), m_nWrite(0), m_nCount(0) { m_vecData.resize(nCapacity, 0.0); } void Push(double v) { m_vecData[m_nWrite] = v; // 覆盖最旧数据 m_nWrite = (m_nWrite + 1) % m_nCapacity; // 写指针回绕 if (m_nCount < m_nCapacity) ++m_nCount; // 有效数据计数封顶 } // 把环形数据展开成线性顺序，供控件一次性读取 // 返回有效点数，输出缓冲需预先保证容量 >= 容量上限 size_t ToLinear(double* pOut) const { if (m_nCount == 0) return 0; size_t nStart = (m_nCount == m_nCapacity) ? m_nWrite : 0; for (size_t i = 0; i < m_nCount; ++i) pOut[i] = m_vecData[(nStart + i) % m_nCapacity]; return m_nCount; } private: std::vector<double> m_vecData; size_t m_nCapacity; size_t m_nWrite; size_t m_nCount; };

这段代码的关键在ToLinear：nStart的取法决定数据是否已经填满。没填满时从 0 开始读，填满后从写指针位置开始读——写指针正好指向最旧的那个点。这段展开是纯内存拷贝，1000 点耗时在微秒级，比起让控件内部排序或扩容，代价可以忽略。缓冲区容量建议比窗口点数留 10% 到 20% 余量，这样即使在两帧之间来了突发的批量数据，也不会丢掉旧窗口里还该显示的部分。

4.2 定时器刷新：把采集和绘制解耦

刷新不要绑在数据到达事件上。数据可能是 1 kHz 来的，但界面 30 到 60 Hz 刷就够了，多刷的部分人眼也看不出来，纯粹浪费 CPU。用SetTimer定一个 33 ms 的周期，在OnTimer里统一取数据、更新序列、请求重绘。

// 启动：对话框初始化末尾开一个 30 fps 的刷新定时器 SetTimer(TIMER_REFRESH, 33, nullptr); void CWaveDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent == TIMER_REFRESH) { // 1) 取出本帧要显示的数据（线性展开） size_t nCount = m_Ring.ToLinear(m_vecLinear.data()); if (nCount > 0 && m_pSerie != nullptr) { // 2) 覆盖式更新：长度恒定，不扩容 if (m_bSerieSizeFixed == false) { m_pSerie->SetPoints(0, m_vecX.data(), m_vecLinear.data(), (unsigned)nCount); m_bSerieSizeFixed = true; // 首次写入点数组长度 } else { m_pSerie->SetPoints(0, m_vecX.data(), m_vecLinear.data(), (unsigned)nCount); } // 3) 只重绘控件区域，别整窗刷新 m_Chart.RefreshCtrl(); } } CDialogEx::OnTimer(nIDEvent); }

m_vecX是预先算好的 X 序列（0、1、2……或者按采样间隔换算的真实时间），初始化时算一次，之后每帧复用，不要在定时器里重新生成，那又是一笔无谓开销。SetPoints的第一个参数是起始下标，从 0 开始覆盖，正好对应“整窗重写”的语义；用它的好处是控件内部的点数组长度保持不变，避免了Clear()之后AddPoints造成的反复分配。

如果采集在独立线程里，不要在采集线程里碰控件对象。正确做法是线程里只往环形缓冲写数据（加个CRITICAL_SECTION或std::mutex保护写指针），UI 线程在定时器里读，或者用PostMessage通知一次“有新数据”，再由界面线程合并处理。直接跨线程调控件方法的后果是随机的断言失败或绘制错乱，这类崩溃最难查。

4.3 绘制开销的三个开关

同样是 1000 点，配置不同，帧耗时能差好几倍。三个必须确认的点：

第一，序列排序已经关掉（poNoOrdering）。默认排序在每次数据变化后都会触发一次比较与重排，实时场景纯属浪费。

第二，坐标轴自动量程慎用。自动量程每帧都要遍历数据求极值，数据量大时开销不小；如果业务允许固定量程，就改成SetAutomatic(false)加SetMinMax。要做自适应，也可以每隔若干帧才更新一次量程，不必每帧算。

第三，重绘范围最小化。确认刷新只针对控件矩形，而不是整个对话框；如果控件上还叠了别的子窗口，检查有没有触发全窗Invalidate。另外，网格线密度也是个隐性成本，密集网格在小尺寸控件里既难看又费时，通常把网格间距调大即可。

把这三条落实，1000 点到 2000 点的实时曲线在普通办公机上跑到 30 fps 是常规水平，不会出现拖影或鼠标卡顿。

5. 避坑与排查：五类最常见的翻车点

这套控件用起来不难，但它的问题很少在编译期暴露，基本都在运行时以“看起来不对”的形式出现。下面五条是我在几个监控界面上反复遇到过的。

5.1 控件位置出现了灰色空框，曲线一条也没有

现象：对话框能起来，原本该显示图表的地方是一个灰色或白色的空白矩形，没有任何坐标轴。

原因：九成是资源里 Custom Control 的 Class 名写错，或者控件类没有被注册到当前进程。子类化时SubclassDlgItem找不到同名窗口类，返回 FALSE，但很多人没检查返回值，于是后面所有对m_Chart的调用都作用在一个没绑定的对象上。

解决：在OnInitDialog里检查SubclassDlgItem的返回值并弹提示；确认资源里 Class 名与源码注册的类名逐字符一致（注意大小写和前后空格）；如果用动态创建，确认Create调用发生在父窗口已创建之后，不要在构造函数里调。

5.2 曲线画出来了，但出现横穿全图的回折线

现象：波形整体是对的，但每隔一段就有一条从右边缘直接连到左边的斜线，看起来像心电图异常。

原因：环形缓冲的数据没有展开成线性顺序，直接把回绕后的数组交给控件，于是“最旧的点”在数组中间，绘制时按数组下标连线，必然出现跨图回折。另一种可能是序列排序没关，控件按 X 排序后与你的预期顺序不一致。

解决：按 4.1 的ToLinear展开后再绘制；确认SetSeriesOrdering(poNoOrdering)已生效；X 值必须是递增或至少单调的，别用循环计数在回绕时归零，那样 X 轴会周期性缩回去。

5.3 跑几分钟就变卡，任务管理器里内存缓慢上涨

现象：刚启动很流畅，五到十分钟后鼠标拖动窗口开始迟滞，内存占用曲线一路向上。

原因：每帧都在Clear()之后重新AddPoints，控件内部的点数组反复申请释放，堆上产生碎片；或者定时器里创建了临时对象（CString、std::vector）没有复用；也可能是采集线程和 UI 线程的缓冲没有做上限控制，队列无限增长。

解决：改用SetPoints覆盖式更新，点数组长度恒定；把所有每帧要用的缓冲（X 序列、线性展开缓冲）提到成员变量里预分配；给线程间队列设上限，满了丢最旧的数据并计数，丢包数显示在界面上，比悄悄堆积要诚实得多。

5.4 缩放之后坐标轴刻度不跟着变，或者缩完就回不去了

现象：鼠标框选放大，曲线放大了，但刻度数字还是原来的；或者连续缩放几次之后画面糊成一片，找不到复位入口。

原因：手动改过轴的SetMinMax又把SetAutomatic关了，控件的缩放逻辑更新的是内部视图范围，而你的固定量程覆盖了它；也可能是缩放后没有触发刷新，视图范围变了但没重绘。

解决：要支持缩放就把轴设为自动量程，让控件自己算；固定量程的需求和自由缩放本身有冲突，二者选一个。另外提供一个“复位视图”按钮，调用控件恢复默认范围的方法再RefreshCtrl，演示时被问到也能从容应对。

5.5 多线程采集时偶发崩溃，堆栈停在绘制函数里

现象：单线程跑一整天没问题，一开采集线程就隔几十分钟崩一次，崩溃位置在控件的绘制或数据更新内部。

原因：采集线程直接调用了序列的AddPoints或控件的刷新方法。MFC 的窗口对象有线程亲和性，跨线程操作窗口和 GDI 资源属于未定义行为，具体表现取决于时序。

解决：采集线程只负责往受保护的缓冲里写数据，所有控件调用集中在 UI 线程的定时器里；线程间通信用PostMessage传递“有新数据”的信号，消息里不带指针；缓冲区读写加锁，锁的粒度控制在拷贝那一段，不要在锁里做绘制。

6. 验收与答辩：用一张测试表证明这套波形是可靠的

功能跑通不等于可以交付。答辩或者评审现场，最容易被追问的是“你怎么知道它不卡、不丢数据、长时间跑没问题”。与其临场解释，不如提前把验收做成一张能当场演示的表。

我的做法是准备四组用例，每组有明确的观察点和通过标准：

演示时有个技巧：把任务管理器或者自己写的状态栏（显示当前帧耗时、丢包计数、缓冲占用）放在旁边，一边跑一边让评审看数字。数字稳定比任何口头描述都有说服力，而且丢包计数这种“主动暴露缺点”的设计，反而会让评审觉得你考虑过边界情况。

回答“为什么不用自绘”这类问题时，别贬低其他方案，讲清权衡：自绘灵活但坐标轴和交互要自己写，通用图表库功能全但集成重，这套控件在原生 MFC 工程里改起来最直接，源码在手，遇到问题能跟进到具体函数。这个回答既专业又不会给自己挖坑。

还有一个细节：把刷新周期、缓冲容量、窗口点数做成界面上的可调项，或者至少在配置文件里能改。评审问“采样率变成 500 Hz 怎么办”，你能当场把参数改掉重跑一遍，这比说“支持扩展”有分量得多。类里的常量全部提取成成员变量，成本很低，收益很大。

从那以后，我每次做带实时曲线的界面，都会先把环形缓冲、线性展开、定时器刷新这三段代码固定成模板，然后在模板上改业务逻辑，绝不临时在OnPaint里凑绘制代码——这么干过一次，后面查了一个下午才定位到是排序开关没关导致的掉帧，血泪经验。希望这套结构和这几条验收思路，能帮你在交方案的时候少走一遍弯路。

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