1. 项目概述：为什么在MFC里做多边形扫描转换，至今仍是图形学教学的“硬核试金石”
“计算机图形学 实验4 多边形的扫描转换（MFC中）”——这个标题一出来，我眼前就浮现出某高校图形学实验室里，十几台老式台式机屏幕泛着微光，学生盯着VC6.0界面里一闪而过的绿色多边形轮廓，手心冒汗敲下InvalidateRect那一刻的紧张感。这不是一个过时的怀旧项目，而是图形学底层能力的一次真实压力测试：它不调用OpenGL或DirectX的现成API，不依赖任何现代渲染管线，而是要求你亲手把数学定义的顶点坐标，一步步变成屏幕上一个个有颜色的像素点。核心关键词就是扫描转换、MFC、多边形填充、边界填充、有效边表（AET）、活性边表（NET）——这几个词背后，是光栅化最原始、最不可绕过的逻辑链条。
这个实验解决的是图形学中最基础也最致命的问题：如何让抽象的几何描述，在离散的像素网格上忠实地“落地”？你画一个三角形，顶点坐标是浮点数，但屏幕只有整数坐标的像素；你定义一条边，它可能穿过多个像素中心，到底哪些像素该被涂上颜色？填满还是描边？边缘要不要抗锯齿？这些看似简单的选择，直接决定了最终图像是否“可信”。它适合三类人深度参考：一是正在啃《计算机图形学》教材的本科生，需要把课本第5章的伪代码真正跑通；二是想补足底层功底的初级图形程序员，MFC虽老，但其消息循环、设备上下文（DC）、GDI绘图机制，恰恰是理解Windows图形栈的绝佳入口；三是准备面试图形岗的求职者——我见过太多候选人能流畅讲出Bresenham算法，却说不清为什么在扫描线Y=100时，要先对边表按X排序再逐个配对填充。这实验不是为了教会你画一个好看的多边形，而是逼你直面“从连续到离散”这一根本性鸿沟。
我带过几届图形学实验课，发现一个铁律：凡是能把这个实验完整跑通、并能现场修改参数（比如把填充色从红色改成渐变、把实心改成镂空、把三角形换成凹多边形）的学生，后续学光照模型、纹理映射时，理解速度明显快一倍。因为扫描转换是所有光栅化操作的“母体”，它训练的不是编码能力，而是空间思维与离散逻辑的双重肌肉记忆。下面我就以一个过来人的身份，把当年在实验室里调试到凌晨两点、打印了七版AET表才搞懂的全过程，掰开揉碎讲清楚。
2. 整体设计思路拆解：为什么非得用AET+NET，而不是简单遍历每个像素？
2.1 核心矛盾：效率与精度的生死博弈
初学者最容易犯的错误，就是写一个双重for循环：外层遍历所有扫描线Y，内层遍历所有像素X，对每个(X,Y)点用“射线法”或“重心坐标法”判断是否在多边形内。代码可能只有20行，但运行起来——卡顿得像PPT。原因很简单：假设窗口是800×600，一个中等复杂度的五边形，这种暴力法要计算48万次点-多边形关系。而实际工程中，一个帧可能要绘制上千个物体，这种O(N×W×H)的复杂度，连60FPS的影子都摸不到。
所以必须换思路：不问“每个像素在不在里面”，而是问“当前扫描线Y，和哪些边相交？交点在哪？”。这就是扫描转换的本质——把问题从二维平面搜索，降维到一维线段求交。而AET（Active Edge Table，活性边表）和NET（New Edge Table，新边表）正是为这个降维服务的两把“瑞士军刀”。
提示：AET不是静态列表，而是一个随扫描线Y递增而动态更新的“工作台”。它只存那些“当前扫描线Y正在穿越”的边，每条边在AET里记录三个关键信息：当前交点X坐标、X方向的增量（即1/斜率）、这条边的终点Y坐标。NET则像一个“待办事项清单”，按Y坐标从小到大排序，存着所有“即将在某个Y值开始活跃”的新边。每次Y推进一行，系统要做三件事：①从AET中删除终点Y≤当前Y的边（它们已走完）；②从NET中取出所有起点Y=当前Y的新边，插入AET；③对AET中所有边的X坐标，按1/斜率增量更新一次。整个过程时间复杂度稳定在O(N+H)，N是边数，H是高度，比暴力法快两个数量级。
2.2 MFC环境下的特殊约束：GDI的“单色笔刷”与“设备坐标系”
很多教程忽略了一个致命细节：MFC的GDI绘图，本质上是“命令式”而非“声明式”。你调用CDC::Polygon()，它内部确实做了扫描转换，但那是黑盒。而本实验要求你手动填充，就必须直面GDI的底层限制：
- 设备坐标系原点在左上角：数学书里的Y轴向上为正，而GDI里Y向下为正。这意味着你在计算交点时，所有Y坐标都要用
clientRect.bottom - y做一次翻转，否则多边形会倒扣在屏幕外。 - GDI填充只能用纯色或简单图案：没有内置的抗锯齿、没有Alpha混合。所以实验默认填充是“硬边”实色。若想模拟软边，你得自己实现高斯模糊核对边缘像素加权——这已是进阶内容，本实验暂不展开。
- CDC对象的“当前画笔/画刷”状态：MFC中，
CPaintDC dc(this)获取的DC，其默认画刷是白色空心（NULL_BRUSH）。如果你忘了调用dc.SelectObject(&brush)，哪怕算法全对，屏幕上也什么都不会显示。这是学生调试时最常踩的“空气坑”。
我当年第一次跑通时，发现多边形只显示了一半，查了三小时，最后发现是顶点数组里混入了一个负数Y坐标（没做边界裁剪），导致GDI在绘制时直接截断。这个教训让我明白：图形学实验不是纯数学，它是数学、操作系统API、硬件坐标系三者的严丝合缝咬合。
2.3 方案选型对比：为什么不用“奇偶规则”而用“非零环绕数”？
多边形填充有两种主流规则：
- 奇偶规则（Even-Odd Rule）：从点向任意方向引一条射线，统计与多边形边的交点数，奇数则在内，偶数则在外。实现简单，对凸多边形友好。
- 非零环绕数（Non-Zero Winding Number）：对每条相交边，根据边的方向（顺时针/逆时针）给交点+1或-1，总和非零则在内。能正确处理自相交、带孔洞的复杂多边形。
本实验标准答案采用奇偶规则，原因很务实：教学目标是掌握AET核心流程，而非处理极端拓扑。奇偶规则下，AET只需维护交点X坐标，填充时按顺序两两配对（X0→X1, X2→X3…），中间所有像素全填。而非零环绕数需为每条边记录方向标志，并在AET中实时累加环绕数，逻辑陡增50%。但我在实际扩展中做过对比：当把一个五角星（典型自相交多边形）喂给两种算法，奇偶规则填出来是“镂空星”，而非零规则填出来是“实心星”——这恰好说明，规则选择不是技术优劣，而是需求定义。你得先想清楚：“我要画的是一个几何形状，还是一个视觉符号？”
3. 核心细节解析与实操要点：从顶点输入到像素点亮的7个生死关卡
3.1 关卡一：顶点预处理——为什么必须做“水平边剔除”与“Y排序”
多边形顶点数据从来不是干净的。你从文件读入或用户鼠标点击得到的顶点，可能包含：
- 水平边（y_i == y_{i+1}）：这种边与任何扫描线都不相交（或完全重合），放入AET毫无意义，还会因斜率无穷大导致除零错误。
- 顶点Y坐标未排序：AET更新依赖Y单调递增，如果顶点乱序，NET构建就会错乱。
我的实操方案是：在构造多边形对象时，立即执行预处理函数PreprocessVertices()：
void CPolygon::PreprocessVertices() { // 步骤1：剔除水平边 for (int i = 0; i < m_nVertices; i++) { int next = (i + 1) % m_nVertices; if (m_pVertices[i].y == m_pVertices[next].y) { // 标记该边为无效，后续跳过 m_bEdgeValid[i] = FALSE; continue; } // 步骤2：确保每条边的起点Y <= 终点Y，便于后续插入NET if (m_pVertices[i].y > m_pVertices[next].y) { SwapPoints(m_pVertices[i], m_pVertices[next]); } } // 步骤3：构建NET，按起点Y排序 BuildNET(); }这里有个隐藏技巧：SwapPoints不只是交换坐标，还要同步交换顶点关联的属性（如颜色索引、纹理坐标），否则后续插值会错位。我曾因漏掉这一步，导致一个渐变填充的多边形，上半部是红色，下半部突然跳成蓝色——查bug时才发现是顶点属性没跟着动。
3.2 关卡二：NET构建——如何用链表实现O(1)插入的“事件驱动”
NET不是简单数组，而是一个按Y坐标分桶的链表数组。标准做法是：声明CList<CEdge*, CEdge*> m_NET[WINDOW_HEIGHT]，但这样内存浪费巨大。更优解是用std::map<int, CList<CEdge*>>，键为Y坐标，值为该Y值下所有新边的链表。插入时：
void CPolygon::BuildNET() { for (int i = 0; i < m_nVertices; i++) { if (!m_bEdgeValid[i]) continue; int next = (i + 1) % m_nVertices; int startY = (int)m_pVertices[i].y; // 向下取整，确保扫描线从整数Y开始 // 插入到map中，自动按Y排序 m_NET[startY].AddTail(&m_Edges[i]); } }关键点在于startY的取整方式。数学上，边从y1到y2，它影响的扫描线范围是[floor(y1), ceil(y2)-1]。但GDI的MoveToEx/LineTo是以像素中心为基准，所以startY必须是floor(y1)，否则第一行扫描线会漏掉。这个细节，教材里往往一笔带过，但实测差1像素，整个填充就偏移了。
3.3 关卡三：AET维护——动态排序与增量更新的“心跳节拍”
AET的核心操作是UpdateAET(int currentY)，它必须在每次Y++后立即调用。其逻辑像心脏起搏器：
- 删除阶段：遍历AET，移除所有
m_yMax <= currentY的边（它们已走到终点）。 - 注入阶段：从
m_NET[currentY]中取出所有新边，插入AET。 - 排序阶段：按当前X坐标对AET中所有边升序排列（为后续配对填充做准备）。
- 增量阶段：对AET中每条边，执行
m_x += m_dx（X坐标按斜率增量更新）。
难点在第3步排序。若用std::sort，每次O(M log M)，M是AET长度，太慢。我改用插入排序：因为AET本身变化不大（每次只增删少量边，且X增量平滑），新插入的边X坐标与邻近边接近，插入排序平均O(M)。代码片段：
void CAET::InsertSorted(CEdge* pEdge) { POSITION pos = m_list.GetHeadPosition(); CEdge* pPrev = NULL; while (pos != NULL) { CEdge* pCurr = m_list.GetNext(pos); if (pCurr->m_x > pEdge->m_x) { if (pPrev == NULL) { m_list.AddHead(pEdge); // 插入头部 } else { m_list.InsertBefore(pPrev, pEdge); // 在pPrev前插入 } return; } pPrev = pCurr; } m_list.AddTail(pEdge); // 插入尾部 }这个优化让1000×1000窗口下，单帧AET更新从12ms降到3ms。性能提升来自对数据局部性的深刻理解——不是盲目套算法，而是看透场景本质。
3.4 关卡四：填充策略——从“X配对”到“像素中心对齐”的毫米级校准
AET排序后，填充逻辑看似简单：取第0、1个边的X坐标，填满中间所有像素；再取2、3个……但这里埋着两个毫米级陷阱：
- 像素中心 vs 像素边界：GDI的
FillRect以矩形左上角为基准，而我们的X坐标是边与扫描线的交点（在像素中心线上）。若直接用(int)x1和(int)x2，会导致“半像素偏移”。正确做法是：left = floor(x1 + 0.5); right = floor(x2 - 0.5);—— 加0.5再取整，强制对齐到最近像素中心。 - 边界像素归属：当两条边交点X坐标恰好是整数（如X=100.0），这个像素该填还是不填？标准做法是“左闭右开”：
for (int x = left; x < right; x++)。这样能保证相邻多边形无缝拼接，不会出现白线或重叠。
我曾为验证这点，专门写了个测试：画两个共享一条边的三角形，一个用x<right，一个用x<=right。结果前者严丝合缝，后者在共享边上出现1像素宽的深色重叠带——这就是“像素哲学”的具象化。
3.5 关卡五：凹多边形特例——“局部极小值”引发的AET“双峰”危机
凸多边形的AET永远是“单峰”：交点X坐标单调递增。但凹多边形（如一个“U”形）在某个扫描线Y上，可能出现4个交点：X1<X2<X3<X4。此时若机械地两两配对（X1→X2, X3→X4），会把U形中间的“空腔”也填满，变成实心块。
解决方案是顶点标记法：在预处理时，对每个顶点计算其左右边的Y值关系，标记为“局部极大值”或“局部极小值”。当扫描线遇到局部极小值顶点时，需向AET中临时插入一条“虚拟边”，让交点数保持偶数，从而维持正确的奇偶配对。具体实现：
// 在顶点V_i处，若V_{i-1}.y < V_i.y 且 V_{i+1}.y < V_i.y，则为局部极大值 // 此时，需将V_i作为新边的起点，插入NET[V_i.y] if (IsLocalMinima(i)) { CEdge fakeEdge; fakeEdge.m_yMin = m_pVertices[i].y; fakeEdge.m_yMax = m_pVertices[i].y + 1; // 虚拟边只占1行 fakeEdge.m_x = m_pVertices[i].x; fakeEdge.m_dx = 0; m_NET[(int)m_pVertices[i].y].AddTail(&fakeEdge); }这个技巧，是图形学教材里“扫描转换”章节的压轴难点。它揭示了一个真理：算法不是万能的公式，而是对现实世界几何形态的敬畏与妥协。
3.6 关卡六：MFC消息循环集成——OnPaint中的“三重缓冲”防闪烁术
在MFC中，直接在OnPaint()里调用扫描转换函数，屏幕会疯狂闪烁。原因是：OnPaint()被频繁触发（如窗口移动、覆盖），每次都会清屏重绘，而你的算法可能耗时几十毫秒，造成视觉撕裂。
工业级解法是内存DC双缓冲：
void CMyView::OnPaint() { CPaintDC dc(this); CRect rect; GetClientRect(&rect); // 1. 创建兼容DC和位图 CDC memDC; memDC.CreateCompatibleDC(&dc); CBitmap bitmap; bitmap.CreateCompatibleBitmap(&dc, rect.Width(), rect.Height()); CBitmap* pOldBitmap = memDC.SelectObject(&bitmap); // 2. 先在内存DC中绘制所有内容（包括扫描转换结果） DrawPolygonOnDC(&memDC); // 你的核心算法在此 // 3. 一次性BitBlt到屏幕DC dc.BitBlt(0, 0, rect.Width(), rect.Height(), &memDC, 0, 0, SRCCOPY); // 清理 memDC.SelectObject(pOldBitmap); }这里的关键是CreateCompatibleBitmap——它创建的位图格式与屏幕完全一致，避免了GDI在格式转换时的额外开销。我测试过，开启双缓冲后，100个动态多边形的帧率从12FPS稳定到58FPS，且无任何闪烁。这提醒我们：图形学不仅是算法，更是与操作系统图形子系统的深度协同。
3.7 关卡七：调试可视化——如何把AET表“画出来”，让抽象数据肉眼可见
算法写对了，但怎么证明？我发明了一套“透明调试法”：在OnPaint()末尾，添加一段调试绘制代码，把当前AET中的所有边，用不同颜色短线画在多边形上方：
// 调试：绘制AET中每条边的当前交点（红色小方块）和方向（蓝色箭头） for (POSITION pos = m_AET.m_list.GetHeadPosition(); pos != NULL; ) { CEdge* pEdge = m_AET.m_list.GetNext(pos); CPoint pt((int)pEdge->m_x, currentY); dc.FillSolidRect(pt.x-2, pt.y-2, 4, 4, RGB(255,0,0)); // 红点 // 画箭头：从pt指向pt+(dx*5, 0) dc.MoveTo(pt); dc.LineTo(pt.x + (int)(pEdge->m_dx * 5), pt.y); }这个小技巧价值千金。当看到AET中红点排成一条斜线，且箭头方向一致，你就知道斜率计算没错；当看到某行红点突然消失，就知道那条边已从AET中删除。最好的调试，不是看日志，而是让数据自己开口说话。
4. 实操过程与核心环节实现：从零开始搭建可运行的MFC扫描转换框架
4.1 环境准备：VS2019 + MFC空项目，避坑指南
虽然标题写“MFC中”，但很多学生用最新VS（如VS2022）新建MFC项目，发现找不到CView类向导，或CDC方法报错。这是因为新版VS默认禁用ATL/MFC支持。正确步骤：
- 安装VS2019（兼容性最好）或VS2022，务必勾选“使用C++的桌面开发”工作负载，并单独勾选“MFC和ATL支持”。
- 新建项目 → “MFC应用程序” → 应用程序类型选“单文档” → 用户界面功能取消所有复选框（去掉工具栏、状态栏等干扰项）→ 完成。
- 在
CMyView.h中，不要手动添加#include <afxwin.h>，VS向导已自动包含。手动加会导致重复定义错误。
注意：绝对不要用“MFC DLL”或“MFC ActiveX控件”模板，它们引入了不必要的COM机制，会让
CDC对象行为异常。我曾因此浪费两天，最后发现是DLL模板里GetDC()返回的DC不支持FillRect。
4.2 核心类设计：CEdge、CAET、CPolygon的职责切分
遵循“单一职责”原则，三个类分工明确：
CEdge：封装一条边的全部属性。成员变量必须包含：class CEdge { public: float m_yMin; // 边起点Y（已排序，保证最小） float m_yMax; // 边终点Y float m_x; // 当前扫描线Y下的交点X坐标（动态更新） float m_dx; // X增量 = 1 / 斜率（注意：斜率= (y2-y1)/(x2-x1)，所以dx = (x2-x1)/(y2-y1)） int m_index; // 边在多边形中的索引，用于调试追踪 };CAET：管理活性边的动态集合。核心是CList<CEdge*> m_list，以及InsertSorted()、UpdateForY(int y)等方法。CPolygon：聚合类，持有顶点数组、NET（std::map<int, CList<CEdge*>>）、AET实例，并提供ScanConvert(CDC* pDC, COLORREF color)主接口。
这种设计的好处是：单元测试极其方便。你可以单独实例化一个CEdge，传入(0,0)->(10,10)，调用UpdateForY(5)，断言m_x是否等于5.0——100%可验证。
4.3 扫描转换主循环：OnDraw中的12行核心代码
CMyView::OnDraw(CDC* pDC)是战场中心。以下是精简后的核心循环（已去除调试和错误处理）：
void CMyView::OnDraw(CDC* pDC) { CPolygon polygon; polygon.SetVertices(m_vertices); // m_vertices是你的顶点数组 // 1. 预处理顶点，构建NET polygon.PreprocessVertices(); // 2. 获取客户区，确定扫描线范围 CRect rect; GetClientRect(&rect); int minY = (int)rect.top; int maxY = (int)rect.bottom; // 3. 主扫描循环：Y从minY到maxY for (int y = minY; y < maxY; y++) { // 4. 更新AET：删除过期边、注入新边、排序、X增量 polygon.UpdateAET(y); // 5. 从AET中提取交点X坐标，存入vector std::vector<float> intersections; for (POSITION pos = polygon.m_AET.m_list.GetHeadPosition(); pos != NULL; ) { CEdge* pEdge = polygon.m_AET.m_list.GetNext(pos); intersections.push_back(pEdge->m_x); } // 6. 按X排序（确保配对正确） std::sort(intersections.begin(), intersections.end()); // 7. 两两配对填充 for (int i = 0; i < intersections.size(); i += 2) { if (i + 1 >= intersections.size()) break; int left = (int)floor(intersections[i] + 0.5); int right = (int)floor(intersections[i + 1] - 0.5); if (left < right && left >= 0 && right <= rect.right) { CRect fillRect(left, y, right, y + 1); pDC->FillSolidRect(&fillRect, RGB(255, 0, 0)); } } } }这段代码的魔力在于：它把教科书上的伪代码，变成了可触摸、可调试、可修改的实体。每一行都有明确的物理意义，没有魔法。
4.4 参数配置与效果调优：3个关键参数的实战取值表
| 参数名 | 物理意义 | 推荐取值 | 调优效果 | 实测案例 |
|---|---|---|---|---|
m_dx计算精度 | X增量的浮点精度 | float（非double） | double在GDI中无意义，反而增加计算开销 | 用double时，1000行扫描线耗时23ms；float仅14ms |
| AET最大长度 | 防止内存溢出的硬上限 | 256（足够应付20边形） | 设为1000会浪费内存；设为16会截断复杂多边形 | 一个24边形星形，AET峰值长度为18，安全余量充足 |
| 扫描线步长 | 是否支持亚像素扫描 | 固定1（整数Y） | 设为0.5理论上可抗锯齿，但GDI不支持半像素绘制，会强制取整 | 尝试y+=0.5后，填充区域出现规律性缺口 |
这张表来自我反复压测27个不同拓扑多边形的结果。它告诉你：参数不是理论最优，而是工程平衡。比如m_dx用float，是因为GDI的MoveToEx函数内部也是float精度，用double只是徒增转换损耗。
4.5 扩展实战：从单色填充到“扫描线渐变”的3步改造
想让多边形不再是死板的红色，而是从顶部蓝色到底部红色的渐变？只需三步改造：
- 在
CPolygon中添加颜色数组：std::vector<COLORREF> m_colors，大小与顶点数相同。 - 修改
CEdge结构：增加float m_colorR,m_colorG,m_colorB，表示该边两端点颜色的线性插值系数。 - 在填充循环中，为每个X位置计算插值色：
for (int x = left; x < right; x++) { // 计算当前X在区间[left, right]中的归一化位置t float t = (float)(x - left) / (right - left); // 插值R、G、B分量（假设m_colors[0]是顶部色，m_colors[1]是底部色） BYTE r = (BYTE)(m_colors[0].rgbRed * (1-t) + m_colors[1].rgbRed * t); BYTE g = (BYTE)(m_colors[0].rgbGreen * (1-t) + m_colors[1].rgbGreen * t); BYTE b = (BYTE)(m_colors[0].rgbBlue * (1-t) + m_colors[1].rgbBlue * t); pDC->SetPixel(x, y, RGB(r,g,b)); }
注意：SetPixel比FillSolidRect慢10倍，所以渐变填充只适用于小面积或多边形数量少的场景。这是性能与效果的经典权衡。
5. 常见问题与排查技巧实录：那些年我们一起踩过的12个坑
5.1 问题速查表：症状、根因、一招毙命解法
| 症状 | 可能根因 | 一招毙命解法 | 我的血泪史 |
|---|---|---|---|
| 多边形完全不显示 | CDC对象未正确获取，或SelectObject未设置画刷 | 在OnDraw开头加ASSERT(pDC != NULL);，并在OnPaint中确认CPaintDC构造成功 | 第一次调试，pDC是NULL，因为OnDraw被误写成OnPaint，编译不报错但永不执行 |
| 填充区域偏移1像素 | 未做Y坐标翻转（GDI原点在左上角） | 在计算交点Y时，统一用scanY = clientRect.bottom - y; | 画一个正方形，结果出现在窗口顶部之外，查了4小时坐标系 |
| 凹多边形中间被填满 | 未处理局部极小/极大值顶点 | 在PreprocessVertices中加入顶点类型判断，并注入虚拟边 | U形多边形测试时，导师指着屏幕问：“这真是U形吗？” |
| 程序运行几秒后崩溃 | CEdge对象在AET中被多次delete，或指针悬空 | 所有CEdge对象由CPolygon统一new/delete，AET中只存指针，绝不delete | 调试器显示0xCDCDCDCD（VC debug heap标记），内存已释放 |
| 填充色是黑色或白色 | COLORREF值错误（如RGB(255,0,0)写成RGB(0,0,255)） | 用TRACE("Color: %06X\n", color);输出十六进制值，对照RGB表 | RGB(255,0,0)是红色，RGB(0,255,0)是绿色，RGB(0,0,255)是蓝色——手抖写反，绿色变蓝色 |
| AET中交点X顺序混乱 | InsertSorted逻辑错误，或未在每次更新后重新排序 | 在UpdateAET末尾加ASSERT检查AET是否有序：for (i=0;i<size-1;i++) ASSERT(x[i] <= x[i+1]); | 交点X乱序导致配对错乱，填出诡异的“之”字形条纹 |
5.2 独家避坑技巧：3个让调试效率翻倍的野路子
技巧1：用“灰度图”替代颜色，快速定位坐标错误
不要一上来就用鲜艳的RGB。先用RGB(g,g,g)，其中g = (BYTE)y（Y坐标值）。这样，每条扫描线都是不同灰度：顶部是黑色，底部是白色。如果看到某行突然变黑，说明那行Y计算错误，立刻聚焦排查。
技巧2：把AET内容实时打印到Output窗口
在UpdateAET函数中，添加：
TRACE("Y=%d, AET size=%d: ", y, m_list.GetCount()); for (POSITION pos = m_list.GetHeadPosition(); pos != NULL; ) { CEdge* p = m_list.GetNext(pos); TRACE("(%.1f,%d) ", p->m_x, (int)p->m_yMax); } TRACE("\n");运行时打开VS的“输出”窗口（Ctrl+Alt+O），就能看到AET随Y推进的完整演化过程。比断点单步高效10倍。
技巧3：制作“最小可复现案例”
遇到诡异bug，立刻新建一个最简多边形：只有3个顶点(10,10),(100,10),(55,100)。如果这个三角形都画不对，说明是核心算法问题；如果它能画对，再逐步增加顶点复杂度。我用这招，把一个“偶数边失效”的bug，从200行代码中精准定位到m_bEdgeValid数组索引越界。
5.3 性能瓶颈诊断：当帧率低于30FPS时，如何科学提速
在1000×1000窗口中绘制50个随机多边形，我的基准帧率是42FPS。若低于30，按此顺序排查：
- 检查
OnDraw是否被意外高频调用：在函数开头加static DWORD lastTime=0; DWORD now = GetTickCount(); if(now-lastTime<33) return; lastTime=now;（强制30FPS上限），若帧率回升，说明是消息洪水（如InvalidateRect滥用）。 - 用VS性能探查器（Profiler）抓热点：90%的性能杀手在
UpdateAET的InsertSorted和FillSolidRect。前者优化见3.3节，后者可批量替换为CDC::Polygon()（但会失去控制权）。 - 关闭所有调试输出：
TRACE在Release模式下不编译，但Debug模式下每行TRACE消耗0.1ms。50个TRACE就是5ms，直接吃掉1/6帧时间。
最后分享一个真实案例：某学生项目帧率仅8FPS，Profiling显示95%时间耗在std::map::insert。他把std::map换成std::vector+手动二分查找，帧率飙升至38FPS——有时候，最“土”的方案，恰恰是最高效的。
6. 实战总结与延伸思考：从MFC实验到现代图形管线的思维跃迁
写完这个实验，我习惯性打开任务管理器，看着那个小小的MFC进程占用0.2%的CPU，心里有种踏实感。它不像Unity或Unreal那样炫目，但它强迫你直视每一个像素的诞生过程：从浮点数交点，到整数坐标，再到显存中的字节。这种“亲手造轮子”的体验，是任何高级框架都无法替代的肌肉记忆。
这个实验的价值，远不止于“会画一个多边形”。它是一把钥匙，打开了三扇门：
- 第一扇门通向现代GPU：今天GPU的光栅化器，其AET逻辑与本实验同源，只是用硬件电路并行实现了
