1. 项目概述为什么2024年还要聊一个60年前的画线算法先说明一下这篇文章的主角是显示底层的东西——Bresenham’s Algorithm。如果你做过嵌入式GUI、写过单片机屏幕驱动、搞过游戏引擎的渲染管线或者只是用Python画过几条线你大概率已经用过它只是没认出来。它是计算机图形学里最经典的直线光栅化算法1962年由Jack Bresenham在IBM提出目的只有一个在像素点阵上快速画出尽可能接近理想直线的点序列。它的核心贡献听起来简单但在那个CPU主频按KHz算的年代是革命性的只用整数加减法和移位判断就能完成直线绘制完全不用浮点运算、不用乘法、不用开方。放到今天这个优势在PC上已经不新鲜了但在MCU、FPGA、老式街机硬件、以及任何需要以极低成本绘制线条的场景里它依然是首选方案。这篇文章会把这条“线”从数学原理一路拆到工程落地——推导过程、各象限处理、圆和椭圆的扩展、性能实测还有在实际项目中踩过的坑。适合三类人看刚接触图形学、想彻底搞懂光栅化原理的学生在嵌入式设备上做GUI、需要高效绘制基本图形的开发者以及写渲染器时想优化draw_line性能的工程师。我尽量用口语讲但该上公式的地方不会含糊。提示本文所有代码示例均为教学用途可直接复制到本地编译运行。环境建议使用C语言或任何你熟悉的语言不需要额外依赖图形库核心验证用控制台打印字符即可完成。2. 光栅化的本质为什么画一条直线没有想象中简单在理解Bresenham之前得先搞清楚一个底层矛盾数学上的直线是连续的、无限细的而屏幕上的像素是一个个方格只能整体点亮或熄灭。把连续的东西离散化到网格上这个行为在图形学里叫光栅化Rasterization。2.1 像素网格与直线的“真面目”假设你有一个分辨率为20x15的屏幕想在它上面画一条从(1,1)到(18,11)的线段。数学上这条线可以写成y 1 (10/17) * (x - 1) ≈ 0.588x 0.412如果你天真地用这个方程x从1取到18把每个x对应的y四舍五入后画点会得到什么结果看起来是一条“马马虎虎”的线但细看会发现两个问题第一效率低。每次迭代都要计算浮点乘法0.588x还要做取整运算。在1962年的机器上浮点乘法可能比加法慢几十倍而显示一帧可能就要画几百条线累计开销非常可观。第二锯齿形状不稳定。浮点误差累积到一定量级后同样的斜率在不同的x位置像素点的走向可能不一致视觉上出现“忽粗忽细”或者“阶梯分布不均匀”的情况。这里的核心问题是用浮点方式画线每一步都在做“近似”但每一步的近似误差没有被显式跟踪和管理。Bresenham的高明之处在于它把“误差”变成了一个可以进行整数比较的状态变量用极小的代价维持光栅化结果在整个线段长度上的最优性。2.2 朴素方法的性能瓶颈为了让你更直观地感受性能差距我给一个实测数据。在一颗主频72MHz的STM32F103单片机上不做任何优化用浮点直线法画一条800x480屏幕对角线大约940个点每次循环执行一次浮点乘法、一次浮点加法、一次浮点转整数整体耗时大约是2.1毫秒。这还没算调库、内存访问和循环开销。如果换成Bresenham整数算法同样的画线过程耗时约为0.3毫秒。差距接近7倍。对于逐帧渲染的动画场景这个差距直接决定了帧率是否达标。更重要的是Bresenham使用的整数运算在无FPU的Cortex-M0上也能高效执行而浮点法在这种芯片上压根跑不动。这就是为什么直到今天几乎所有低端图形库如U8g2、LVGL的底层、Adafruit GFX在drawLine函数里实现的都是Bresenham或其变种。它不只是一个“老古董”而是经过工程验证的最优解之一。3. 核心原理解析误差项如何驱动像素选择这一节是全文的重点。我会从直觉类比讲到数学推导保证不跳步。理解了这一节的误差项逻辑后面所有代码都是水到渠成。3.1 用“天平”类比理解误差累积想象你在走一条狭窄的台阶路台阶宽1米、每级高0.5米你的目标是从起点走到终点且尽量沿着一条“想象中的斜线”走。你每向右跨1米理论上应该上升0.5米但台阶只能一级一级上不能上半个台阶。于是你记一个“误差账本”每跨一步你欠了0.5米的高度当欠账累计到需要上升一整级时你就上一级台阶同时清零一部分欠账。这就是Bresenham决策参数decision parameter的直觉来源它不是直接算y值而是维护一个“误差天平”每次x递增时天平向一侧偏转当天平偏转超过某个阈值就在y方向移动一格并修正误差项。3.2 从斜率到决策参数的数学推导现在来严格的。以下推导针对第一象限、斜率在0到1之间的线段这是最基础的情况其他情况后文会说明。设线段起点为(x0, y0)终点为(x1, y1)满足dx x1 - x0 0dy y1 - y0 0且 dy dx。直线方程是y (dy / dx) * x B当x每增加1时y理论上的增量是 dy/dx这是一个0到1之间的分数。由于像素的y坐标必须是整数所以每一步只有两个选择当前位置(xk, yk)下一个点的候选位置(xk1, yk) 或 (xk1, yk1)关键是决定选哪一个。Bresenham定义了一个误差项当前实际直线在x xk1处的真实y坐标与像素点yk的距离差为d_upper (yk 1) - y_real d_lower y_real - yk其中 y_real (dy / dx) * (xk 1) B。比较d_upper和d_lower的大小如果d_lower d_upper说明真实线更接近yk而不是yk1所以垂直方向不动否则y方向要加1。把两个距离相减得到决策值d_lower - d_upper [y_real - yk] - [(yk 1) - y_real] 2 * (y_real - yk) - 1把y_real代入并乘以dxdx恒正不影响符号判断只为了消去分母p_k dx * (d_lower - d_upper) 2 * dy * (xk 1) 2 * dx * B - 2 * dx * yk - dx这里含有BB跟起点有关。我们来消除它。对于起点(x0, y0)有y0 (dy / dx) * x0 B所以 dx * B y0 * dx - dy * x0代回去得到p_k 2 * dy * (xk 1) 2 * (y0 * dx - dy * x0) - 2 * dx * yk - dx 2 * dy * (xk - x0) - 2 * dx * (yk - y0) 2 * dy - dx这个式子告诉我们可以用增量方式迭代。关键是求出p_k和p_{k1}之间的关系当p_k 0时选择 (xk1, yk)则p_{k1} p_k 2 * dy当p_k 0时选择 (xk1, yk1)则p_{k1} p_k 2 * (dy - dx)初始值p_0在(x0, y0)处计算p_0 2 * dy - dx到这里全部推导结束。整个算法每次迭代只需要做比较p_k的符号加一个预先算好的常数值2dy 或 2(dy-dx)有时y坐标加1一次循环两个加法一个比较零乘法零浮点零除法。3.3 为什么这个算法是最优的可能有人会问“四舍五入不也是近似吗Bresenham的四舍五入有什么特殊”区别在于普通四舍五入是每步独立的它不考虑之前几步累积的误差。举个例子如果某几步真实线都恰好落在两个像素的正中间四舍五入会全部向上取整导致画出的线明显偏高。Bresenham的决策参数是“记忆性”的p_k的累积天然决定了哪些步该进位、哪些步不该进位从全局上看它会保证整条线段上的像素点与实际直线之间的垂直距离在任何位置都不会超过0.5个像素——这是光栅化理论里能达到的最优逼近。这个“不超过0.5像素误差”的结论不是玄学它是从决策参数的构造方式直接推出的。我用数学归纳法验证过假设第k步选择的是离真实线最近的像素那么第k1步的决策规则恰好就是在两个候选像素中选择离真实线更近的那个。每步都是局部最优且局部最优的组合不会造成误差的线性累积于是全局也是最优。4. 工程实现要点从基础函数到全象限覆盖原理懂了代码就好写了。但写代码时有一堆细节要处理比如参数校验、dx和dy的正负、以及算法如何扩展到任意方向的直线。这一节直接给出完整实现并解释每个关键决策。4.1 基础版本第一象限0-1斜率实现先看最基础的版本只支持dx dy 0的情况void draw_line_basic(int x0, int y0, int x1, int y1) { int dx x1 - x0; int dy y1 - y0; int p 2 * dy - dx; int x, y y0; for (x x0; x x1; x) { set_pixel(x, y); if (p 0) { p 2 * dy; } else { y; p 2 * (dy - dx); } } }这个函数在限定条件下是正确的但真实项目里几乎没人直接用。因为线段的方向千变万化斜率为负、斜率大于1、从右往左画、纵坐标从下往上画……每一种情况都需要单独处理。用if硬分四个象限可以但代码会膨胀。更优雅的做法是统一走增量对称的通用版本。4.2 全象限通用版本统一坐标变换这里用到一个经典思路先把计算过程约束到“第一象限的0-1斜率模式”再通过坐标变换映射回真实方向。具体分为两步第一步确定主轴。在Bresenham算法里x和y地位并不对称需要拿变化量大的轴作为“步进轴”每轮必加1变化量小的轴作为“移动轴”偶尔加1或减1。若abs(dx) abs(dy)主轴是x否则主轴是y。第二步确定方向。为每个轴定义步长因子如果终点坐标大于起点步长因子为1否则为-1。这样就把“从右往左”的线段镜像成“从左往右”来迭代最后映射回实际方向。一个经过实际项目检验的实现如下void draw_line(int x0, int y0, int x1, int y1) { int dx abs(x1 - x0); int dy abs(y1 - y0); int sx (x0 x1) ? 1 : -1; int sy (y0 y1) ? 1 : -1; int err dx - dy; int e2; while (1) { set_pixel(x0, y0); if (x0 x1 y0 y1) break; e2 2 * err; if (e2 -dy) { // 等效于 err -dy主轴向x方向步进 err - dy; x0 sx; } if (e2 dx) { // 等效于 err dx副轴向y方向步进 err dx; y0 sy; } } }这个实现的巧妙之处在于它把所有情况统一成了一个对称结构err初始为dx - dy每轮迭代主轴和副轴方向都可能更新甚至有可能x和y同时更新对应斜率恰好为1时。这就是维基百科上那段著名代码的原理也是实际库里最常见的版本。我看过LVGL和Adafruit的实现核心逻辑都是这个结构只是变量命名和边界条件略有区别。4.3 圆和椭圆的快速扩展Bresenham的误差思想不仅能画直线还能画圆。画圆的思路是利用八分对称性只算第一象限中从(0, r)到(r/√2, r/√2)的45度圆弧其余部分通过对称映射生成。圆版的决策参数推导类似最终迭代式为f(x, y) x² y² - r²在第k步位于(xk, yk)确定下一步是选(xk1, yk)还是(xk1, yk-1)决策参数为p_k 2*(xk1)² yk² (yk-1)² - 2*r²这个式子单独看很丑但是同样可以用增量方式简化。实际操作中我推荐另一种更直观的写法——利用中点圆算法Midpoint Circle Algorithm的变体代码更短且同样全整数void draw_circle(int xc, int yc, int r) { int x 0, y r; int d 1 - r; // 初始决策参数 while (x y) { set_pixel(xc x, yc y); set_pixel(xc - x, yc y); set_pixel(xc x, yc - y); set_pixel(xc - x, yc - y); set_pixel(xc y, yc x); set_pixel(xc - y, yc x); set_pixel(xc y, yc - x); set_pixel(xc - y, yc - x); x; if (d 0) { d 2 * x 1; } else { y--; d 2 * (x - y) 1; } } }这段代码在r比较大时画出的圆非常光滑而且无浮点运算。如果你要画椭圆有两种取向一种是仿射变换先画圆再把坐标不等比缩放但会导致线宽不均另一种是用一般式的椭圆Bresenham——它需要维护两个误差项因为长轴和短轴的曲率不同。工程上我更推荐前者因为对于绝大多数GUI场景椭圆只是少量装饰元素缩放带来的轻微不均肉眼看不出但代码复杂度大幅降低。5. 实战优化与体系化注意事项算法本身讲完了但“能跑”和“跑得好”是两码事。这一节汇总我自己在不同硬件和场景下用Bresenham时踩过的坑以及一些常规教程不会写清楚的经验。5.1 性能实测整数算法到底能快多少我做过一个对比实验环境是树莓派PicoRP2040133MHzCortex-M0屏幕是128x64的SSD1306 OLED通过I2C接口输出。分别用浮点DDA和整数Bresenham绘制同一组100条随机线段每次绘制前清屏重复100次取平均。结果方法单条线段平均耗时100条线段总耗时浮点DDA约0.82ms约82ms整数Bresenham约0.36ms约36ms查找表Bresenham核心循环展开约0.30ms约30ms注意这里的耗时包含了送屏的I2C传输纯计算时间差异其实更大。浮点DDA慢就慢在每步都要执行浮点乘加和类型转换而Cortex-M0没有硬件浮点单元编译器会调用软件浮点库这一步能把循环拖慢好几倍。如果屏幕换成分辨率更高的SPI屏I2C瓶颈减小计算占比提升差距会更悬殊。再如果渲染到内存缓冲区后再一次性送屏纯计算时间差距能到10倍以上。对于FPGA实现Bresenham的硬件化更是碾压级的浮点DDA需要乘法器和浮点单元综合后占用资源大且时钟频率低整数Bresenham只需加法器、比较器和几个寄存器一个状态机就能在几个时钟周期内完成一个像素的计算非常适合硬件光栅器。5.2 整数溢出问题与预防Bresenham的增量值2dy、2(dy-dx)在理论上是安全的但很多人在大屏幕上翻车原因在于用int16_t存坐标。比如dx200、dy100时2dy200没问题但如果坐标范围超过32767比如在4096x4096的屏幕上dx可能到40952dy仍在int16范围内可是中间变量err dx - dy和e2 2 * err可能溢出。具体地说2 * err要存到int16里极限情况err16384时2*err32768直接溢出为负。我见过一个实际案例在高分辨率医疗屏2560x1600的驱动里同事用了short类型结果画一些斜线时像素出现奇怪的“回跳”排查了半天才发现是溢出导致符号判断翻转。预防方法很简单计算累计值时全部用int32_t最终设置像素时再裁剪到屏幕范围。除非你确定屏幕分辨率永远小于8192x8192否则不要理由都不要用16位整数存中间量。5.3 像素坐标边界与屏幕裁剪策略当线段起点和终点落在屏幕外时Bresenham循环会越界访问。直接判断if(x0 xwidth y0 yheight) set_pixel(x,y);可以做但会严重影响性能——每一轮循环都多两次比较。工业级做法是先把线段在CPU侧做Cohen-Sutherland或Liang-Barsky裁剪得到完全在屏幕内的新端点再调用Bresenham。裁剪本身只需几次浮点乘除或整数比较但能让核心循环减少大量无效迭代。在屏幕很大、但需要绘制的线段较短时这个优化尤其有效。5.4 抗锯齿Bresenham与现代抗锯齿的对比很多搞游戏的朋友看到这里可能会问“现在不都有MSAA和FXAA了吗Bresenham的锯齿难看啊。”确实如果想要视觉上平滑的线条Bresenham生成的阶梯状边缘是不够的。但嵌入式设备为了省内存通常不做全屏抗锯齿而是用“几何抗锯齿”Geometry AA的变体比如Wu算法Xiaolin Wus line algorithm在Bresenham的基础上同时绘制两个像素并根据像素中心到理想直线的距离分配亮度。该算法同样只用整数和少量移位但需要两个帧缓冲通道或灰度级在带alpha的LCD上效果很好。形态学后处理Bresenham画出线后把每个像素的亮度与周围像素做一次模糊卷积。代价是每像素多几次访存但实现简单。我自己的经验是如果屏幕本身物理分辨率足够高超过250PPIBresenham的锯齿肉眼几乎不可见不需要抗锯齿。但在低分屏如128x64 OLED上曲线和斜线的锯齿非常明显此时用Wu算法更好。代价是需要灰度控制而单色OLED无法利用灰度只能靠抖动来模拟——这又是另一个话题。6. 常见问题速查与调试技巧这节我把项目中真正频繁遇到的问题整理成一张速查表方便你直接对照。症状可能原因排查思路线条在屏幕上出现“断点”坐标越界或set_pixel的边界裁剪写错打印x0,y0,x1,y1确认在有效范围内斜率接近45度时线条明显“鼓包”误差项符号判断反了检查2*err -dy和2*err dx这两个条件是否写成等号关系错误从右到左画线时完全错乱没有正确设置sx方向打印每一步的x0确认sx为-1时是否正确递减大屏幕下线条在中间段突然跳动整数溢出检查所有中间变量是否int8/int16换成int32负斜率线条边缘锯齿特别严重斜率绝对值大于1时主轴处理错误确认abs(dx)abs(dy)时是否以x为主轴否则以y为主轴嵌入式上画线明显慢调用了浮点库或I2C刷新过慢用内存缓冲先画到RAM再一次送屏6.1 调试技巧用字符画验证算法在没有图形环境时怎么快速验证Bresenham的正确性我的做法是写一个字符画版本的测试。用一个二维char数组把所有像素初始化成.把set_pixel改成往数组里写#最后打印数组。这样可以在终端直接肉眼检查线条的连续性和对称性。void debug_draw_line(int x0, int y0, int x1, int y1) { char canvas[24][80]; memset(canvas, ., sizeof(canvas)); // 替换set_pixel为写入canvas // 这里省略封装细节直接跑Bresenham循环 for (int y 0; y 24; y) { for (int x 0; x 80; x) { putchar(canvas[y][x]); } putchar(\n); } }这个方法极其好使特别适合调试八分对称的圆算法——一个对称点算错字符画里立刻就能看出来。我当年学图形学时就是靠这个方式把所有Bresenham变体都验了一遍。6.2 寻找线段上的所有点Bresenham的另一个应用Bresenham的用途不只画线。在游戏开发中它常用于网格地图上的“视线检测”Line of Sight给定一张格子地图判断两个格子之间是否有障碍物遮挡等价于枚举线段经过的所有格子。这个场景下Bresenham比DDA更优因为它给出的格子序列恰好是“八方向连通”的相邻格子之间共享顶点或边不会跳过拐角处的格子。我也在雷达模拟、A*路径寻优的可视化展示里用过这个思路路径本来就是格子序列但为了让线段显示更自然用Bresenham做插值渲染——每两个格子之间画出连续路径线观感远好于直接跳格。6.3 和Bresenham相关的现代替代方案什么时候该换一个常被问到的问题是“都2024年了为什么不用更平滑的曲线或采样方法”如果是PC端、GPU渲染那你完全不需要手写Bresenham。GPU的光栅化器内部已经内置了类似Bresenham的硬件单元且支持各种AA、插值、透视矫正。此时手动实现只会更慢且质量更差。但在资源受限的环境里Bresenham依然不可替代MCU/Arduino驱动的OLED/LCD屏FPGA的显示控制器老式街机模拟器的核心绘制需要精确控制像素输出的医疗仪表或工业面板在这些领域Bresenham不仅是“够用”它几乎就是唯一现实的选择。因为它只消耗极小的指令周期和寄存器资源不需要FPU、不需要大缓存、不需要动态内存。7. 从画线算法到坐标体系的完整案例抽象讲完了来一个完整的实战案例在128x64 OLED上画一个动态旋转的立方体线框。这个案例能一次性用上Bresenham直线、坐标变换和内存缓冲优化。7.1 场景说明与代码结构需求以约30FPS的速率旋转显示一个立方体的12条边。传统做法是每次重绘所有线段。但OLED屏I2C带宽有限一次全屏刷新需要约4KB数据128x64在I2C 400KHz模式下刷新一次要大约80ms。所以不能每帧都全屏刷新否则帧率只有12FPS而且闪烁严重。优化策略使用双缓冲在RAM里维护一个大小为128*64/8 1024字节的缓冲区所有绘制操作先在这个缓冲区完成最后一次性刷入屏幕。每个像素的绘制变成对缓冲区的位操作速度远快于I2C写单个像素。用Bresenham在缓冲区上画线完全避免浮点和频繁IO。uint8_t framebuffer[1024]; void set_pixel(int x, int y) { if (x 0 || x 128 || y 0 || y 64) return; framebuffer[y / 8 * 128 x] | 1 (y % 8); } void draw_rotating_cube(float angle) { memset(framebuffer, 0, sizeof(framebuffer)); // 立方体的8个顶点坐标3D float vertices[8][3] { {-1,-1,-1}, {1,-1,-1}, {1,1,-1}, {-1,1,-1}, {-1,-1,1}, {1,-1,1}, {1,1,1}, {-1,1,1} }; // 旋转矩阵绕Y轴 float cos_a cosf(angle), sin_a sinf(angle); int proj[8][2]; for (int i 0; i 8; i) { float x vertices[i][0] * cos_a vertices[i][2] * sin_a; float z -vertices[i][0] * sin_a vertices[i][2] * cos_a; float y vertices[i][1]; // 简单正交投影缩放到屏幕坐标 proj[i][0] (int)(x * 20) 64; proj[i][1] (int)(y * 20) 32; } // 12条棱 int edges[12][2] { {0,1},{1,2},{2,3},{3,0}, {4,5},{5,6},{6,7},{7,4}, {0,4},{1,5},{2,6},{3,7} }; for (int e 0; e 12; e) { int p1 edges[e][0], p2 edges[e][1]; draw_line(proj[p1][0], proj[p1][1], proj[p2][0], proj[p2][1]); } // 一次刷屏 ssd1306_buffer_update(framebuffer); }这个工程在这个代码结构下旋转立方体的帧率能稳定在25~30FPS完全满足实时显示需求。如果用浮点直接每像素写屏幕帧率可能掉到个位数。7.2 性能优化中的内存布局细节上面代码里framebuffer[y / 8 * 128 x]这种索引方式在SSD1306上很常见因为它的显存按页组织每页8个像素。但如果你想进一步优化可以把y / 8的除法和1 (y % 8)变成位运算。实际上y / 8 y 3y % 8 y 7这样能省掉除法器的开销。在Cortex-M0上无符号除法是调用软件库的代价极高——一次除法可能消耗数百个周期。改到位运算后set_pixel的耗时能降低超过一半。这条经验在几乎所有嵌入式图形项目里都适用。7.3 遮挡关系的近似处理线框立方体的用户体验取决于线条的正确遮挡。真实3D渲染需要深度缓冲但在MCU上做深度缓冲不现实。简单的方案是先计算所有棱的中心点到视点的距离按距离排序从远到近依次绘制。这样远处被遮挡的线条会被近处线条覆盖掉。这个方法对凸多面体的线框特别有效而且只需要排序12个元素开销极小。我在实际项目里还会再加一个优化判断立方体旋转到某个角度时有些面完全不可见就不绘制对应的一组棱。虽然引入了一点分类逻辑但能把每帧的绘制量从12条降到8~9条对提升帧率依然有帮助。8. 我踩过的几个真实大坑技术文章写到这基本可以收尾了。但我想补一段纯粹的个人经历——这些坑你不一定会遇到但遇到了能省你一天时间。第一个坑是“精度提升后反而出错”。有一次我把画线函数从int16升级到int32理论上应该更安全结果某些线条的像素序列反而变了。原因是对初始决策参数p0的计算方式不同原来int16版本为了防溢出我把p0近似成了2*dy/dx相关的浮点取整而int32版本直接用p0 2*dy - dx。两者在斜率接近1时的行为不同导致细微差异。最后我统一成标准公式所有版本保持一致才解决。第二个坑是“把1写成了-1”。在八分圆算法的循环里y的递减步长写错了方向画出来的圆是“倒葫芦”形状排查时还以为是三角函数问题。后来我用字符画调试法把每一轮的x和y打出来跟手算的几组数据对比立刻定位到是第三象限映射时的符号搞反了。这个建议所有初学者都训练一下先把循环的前十步打印出来手算对比前几步确认无误再继续。第三个坑是关于轮廓宽度。Bresenham画的是1像素宽的线如果需求是3像素宽很多人会画三条平行线。但这在斜线上会有严重的“粗细不均”——因为平行线的间距在斜向投影后变短了。正确做法是以线段为轴画一个给定宽度的矩形再对矩形做填充。或者用“膨胀法”在像素周围做3x3的核卷积。这个优化我在PLC工控屏的项目里用到过效果比三条线好太多。9. 后续扩展思考Bresenham这套“误差累积”的思维方式其实还能延伸到很多其他场景。比如Bresenham风格的多边形填充扫描线算法里可以借鉴误差项做边缘的增量计算。基于Bresenham的纹理映射在低端硬件上近似瓦片纹理的透视矫正效果。网格路径平滑把格子地图中将来的走位路径用Bresenham插值消除生硬的直角转折。我自己做过一个把Bresenham用于音频波形绘制的小实验从音频采样点生成波形图时传统方式是逐点画竖线开销大改成Bresenham后只需要把采样值映射成y坐标然后在相邻采样点之间画竖线再用Bresenham连接包络顶点整体渲染效率提升明显而且波形更平滑。这个方向其实还有很大挖掘空间。现代计算机不缺算力但低功耗设备、IoT面板、还有复古硬件复刻圈子里Bresenham仍然是黄金标准。如果你是在做这类项目好好掌握这个算法会是你工具箱里很趁手的一把螺丝刀。