C#毛笔字算法源码解析：笔锋生成与平滑渲染实战

简介：毛笔字算法是计算机图形学中模拟传统书法效果的核心技术，涵盖笔触粗细变化、颜色晕染和笔画间的相互影响。资源以C#源码形式完整实现了毛笔字、笔锋与平滑三类算法，可直接编译运行，便于开发者在图形处理、数字艺术和游戏特效等领域借鉴应用。整个压缩包共47个文件，体积约809KB，其中15个源码文件承担主要算法逻辑，辅以示例图片、窗体配置和可执行文件，便于对照展示运行效果。目前已有715人浏览学习，说明该实现具备不错的参考价值。阅读源码可掌握笔尖压力、角度与速度的建模方式，理解平滑滤波在去除锯齿边缘、优化笔迹过渡方面的作用，也可学习矢量图形渲染与自绘引擎的组合思路，适合中高级开发者用于钻研数字书法模拟技术。

1. 毛笔字算法 C# 源码：一份能编译的手写笔锋实现

做图形处理的人第一次拿到“毛笔字算法”相关源码时，最怕的就是一堆理论公式砸过来，结果项目编译都过不了。这份 C# 源码包属于“麻雀虽小五脏俱全”的类型——有 WinForms 界面、有独立的算法类、有资源文件，直接打开test.sln就能跑。它的核心价值集中在三个点上：通过轨迹点模拟笔锋的宽窄变化、用平滑算法消除手写输入的锯齿感、以及用 GDI+ 实时渲染出接近真实毛笔的书写效果。适合两类人：一类是做数字书法、签字板、绘画软件又想搞明白笔锋是怎么算出来的开发者；另一类是刚接触 C# 图形编程、需要一个能下断点调试的完整 Demo 做跳板的学习者。这篇笔记我按拆包思路来写，从算法原理讲到编译运行，再讲到集成进真实项目的做法，尽量让新手跟得上、熟手有收获。

2. 项目结构与核心类职责：先搞清楚 GClass 是什么来头

2.1 源码包里每个文件是干什么的

打开压缩包先别急着双击.sln，花两分钟把文件结构过一遍，能省下后面一大半排查时间。从提供的文件清单看，项目整体是一个典型的 WinForms 单窗口程序，核心逻辑文件集中在test目录下。

Form1.cs是主窗体逻辑，负责鼠标事件采集和画面刷新调度；Form1.Designer.cs是设计器生成的界面布局代码，一般不直接改；Program.cs是入口；Class1.cs、Class2.cs、GClass0.cs、GClass1.cs、GClass2.cs这五个是算法层——其中GClass前缀的命名方式，说明作者在发布前用混淆工具处理过类名，本质是GestureClass或GraphicsClass级别的封装。Global.cs放全局常量或静态变量，比如画布尺寸、默认笔宽、采样阈值这些，调参时优先看这里。

Form1.resx和Properties下的Resources.resx存的是界面资源和图片资源。dfs.jpg和索引.png两张图，大概率是测试用的背景参考图或笔刷纹理。如果跑起来后发现画布有背景图，找这两个文件就对了。

2.2 从文件依赖关系推断实现思路

WinForms 的项目通常遵循“事件采集 → 轨迹预处理 → 算法生成笔画 → 重绘”这条链路。Form1.cs里的MouseDown、MouseMove、MouseUp三个事件负责把鼠标轨迹变成Point点集；接着调用Class1或Class2里的静态方法做平滑和笔锋计算；最后在Paint事件里通过 GDI+ 把结果画到Graphics对象上。

App.config里大概率存了与 DPI 或渲染质量相关的配置项；test.csproj是工程文件，编译时要注意目标框架版本——如果打开工程时提示需要安装 .NET Framework 4.x 开发包，直接装即可。整个项目没有引入第三方库，渲染质量完全取决于 GDI+ 自身能力，这也意味着边缘抗锯齿需要自己通过SmoothingMode来控制。

2.3 主要文件的快速体检顺序

test.sln -- 解决方案入口，双击用 VS 打开 test.csproj -- 工程文件，确认目标框架和平台 Form1.cs -- 主逻辑，看鼠标事件怎么写 Class1.cs / Class2.cs -- 核心算法，看平滑和笔锋实现 Global.cs -- 全局参数，调参入口

拿到源码后我建议先建一个空白的 WinForms 工程，把上述文件按依赖关系逐个添加进来，这样能看到编译错误一条条暴露依赖关系。GClass文件之间互相引用比较频繁，如果一次性全部添加后出现“找不到类型”的错误，多半是文件没加全或者命名空间不一致，检查namespace声明即可。

3. 笔锋算法：一笔下去为什么两头尖中间鼓

3.1 笔锋的本质：宽度变化不是一个固定值

笔锋这东西，说白了就是笔画在空间上的宽度分布。真毛笔写字时，笔尖压下→行笔→提笔，三个过程对应的笔宽分别是“细→粗→细”，而且转折处因为顿笔会有局部鼓包。计算机里模拟这个效果，最朴素的思路就是取轨迹点的前后差分，算出每个点的瞬时速度，速度越快笔锋越收敛，越慢则笔锋散开变粗。

// 根据采样点速度计算该点的笔宽 private float GetWidthBySpeed(PointF current, PointF prev, float baseWidth) { float dx = current.X - prev.X; float dy = current.Y - prev.Y; float distance = (float)Math.Sqrt(dx * dx + dy * dy); // 速度近似用距离代替，距离越短代表停顿越久，笔锋越粗 float speedFactor = Math.Min(distance, 12f) / 12f; // 12f 是距离阈值，可调 float minWidth = baseWidth * 0.2f; // 最小宽度，细笔锋 float maxWidth = baseWidth * 1.4f; // 最大宽度，按压力度 return maxWidth - (maxWidth - minWidth) * speedFactor; }

这段代码的逻辑是拿相邻采样点的距离近似速度。距离越大说明鼠标移动越快，此时笔锋应该收敛变细；距离短说明光标停滞或缓慢，笔尖压纸时间长，宽度膨胀。baseWidth是基础笔宽，从Global.cs读；minWidth给个 0.2 倍下限是为了避免线条完全消失；maxWidth给个 1.4 倍上限是为了控制鼓包不至于太突兀。

3.2 笔画端点怎么“收尖”

只靠速度控制宽度还不够，笔画起笔和收笔必须做二次处理，否则首尾两端是截断的平头效果，看着像被刀切过。常见做法是计算笔画首尾两端的切线方向，把最后几个采样点的宽度按线性或指数方式递减到接近零。

public List<StrokePoint> ApplyTaper(List<StrokePoint> points, int taperCount) { if (points.Count < taperCount * 2) return points; for (int i = 0; i < taperCount; i++) { float ratio = (float)i / taperCount; // 0~1 渐入渐出 float taper = 1f - ratio; // 端点为 0，逐渐恢复 // 首端收尖 var head = points[i]; head.Width *= taper; points[i] = head; // 末端收尖，索引对称 var tail = points[points.Count - 1 - i]; tail.Width *= taper; points[points.Count - 1 - i] = tail; } return points; }

taperCount一般设 5~10，值越大，首尾拖出的细丝越长，越接近毛笔的“飞白”效果。这里要注意的是，当taper接近零时宽度也接近零，GDI+ 画宽度为零的线条在某些版本下会崩溃或画出异常像素，所以下限建议钳制在0.01f而非真正的0f。

3.3 转折处顿笔效果：方向变化率是关键

一笔写到转折处，真毛笔会有一个短暂的“按笔”动作，反应在轨迹上就是曲率突变处的宽度增加。这个效果可以和 3.1 的速度模型合并，也可以单独加一层“转折检测”：

private float GetTurnBoost(PointF current, PointF prev, PointF next, float currentWidth) { Vector2 v1 = new Vector2(current.X - prev.X, current.Y - prev.Y); Vector2 v2 = new Vector2(next.X - current.X, next.Y - current.Y); // 归一化后点积得到夹角余弦，值越小角度越大 float dot = (v1.X * v2.X + v1.Y * v2.Y) / (v1.Length() * v2.Length()); float angle = (float)Math.Acos(Math.Clamp(dot, -1f, 1f)); // 弧度 // 角度大于 0.5 弧度认为发生明显转折，加宽 30% if (angle > 0.5f) { return currentWidth * 1.3f; } return currentWidth; }

角度阈值 0.5 弧度约等于 28 度，实际调参时可以从 0.3 试到 0.8。阈值太小的话整个笔画到处鼓包，没有主次；阈值太大则转折处没有反应，笔锋出不来。这段代码在真实项目中通常会和速度模型做加权融合，避免两种效果叠加后宽度失控。

4. 平滑算法：采样点噪声与轨迹曲线重建

4.1 鼠标采样为什么需要平滑

鼠标或者手写板的原始采样频率有限，手稍微一抖就会产生小锯齿。如果不做处理直接连线画出来，笔画边缘肉眼可见地“毛”。平滑算法要做的就是在保留笔画主体形状的前提下，把这些高频抖动滤掉，同时不能明显缩短笔画长度。

实际项目中比较常用的是两层处理：先用滑动窗口平均去掉毛刺，再用 Catmull-Rom 样条做插值加密，让曲线过渡更自然。第一个方案是低通滤波思路，第二个方案是在关键点之间补出中间帧。

4.2 滑动窗口平均：最简单也最容易翻车

public List<PointF> SmoothPoints(List<PointF> input, int windowSize) { if (input.Count < windowSize) return input; List<PointF> result = new List<PointF>(); int half = windowSize / 2; for (int i = 0; i < input.Count; i++) { float sumX = 0f, sumY = 0f; int count = 0; for (int j = -half; j <= half; j++) { int idx = i + j; if (idx >= 0 && idx < input.Count) { sumX += input[idx].X; sumY += input[idx].Y; count++; } } result.Add(new PointF(sumX / count, sumY / count)); } return result; }

windowSize决定平滑力度，3 是轻微去毛刺，7 以上就会明显“钝化”笔画，快速书写时的锐利转折会丢失。真实项目中这个参数一般做成全局配置项，让用户在“更平滑”和“保留笔锋”之间拖一个滑块调平衡。

4.3 Catmull-Rom 插值：曲线经过每个采样点

这是对比贝塞尔曲线最大的优势：Catmull-Rom 插值曲线严格经过原始控制点，而贝塞尔曲线只是逼近控制点，用在书法上会导致笔画边界与手写轨迹产生肉眼可见的偏移。Catmull-Rom 是三次插值，每段需要四个控制点，输出则按张力参数插出中间点：

public List<PointF> CatmullRomInterpolate(List<PointF> points, int samplesPerSegment) { List<PointF> output = new List<PointF>(); for (int i = 0; i < points.Count - 1; i++) { PointF p0 = points[Math.Max(i - 1, 0)]; PointF p1 = points[i]; PointF p2 = points[i + 1]; PointF p3 = points[Math.Min(i + 2, points.Count - 1)]; for (int s = 0; s < samplesPerSegment; s++) { float t = (float)s / samplesPerSegment; float t2 = t * t; float t3 = t2 * t; float x = 0.5f * (2f * p1.X + (-p0.X + p2.X) * t + (2f * p0.X - 5f * p1.X + 4f * p2.X - p3.X) * t2 + (-p0.X + 3f * p1.X - 3f * p2.X + p3.X) * t3); float y = 0.5f * (2f * p1.Y + (-p0.Y + p2.Y) * t + (2f * p0.Y - 5f * p1.Y + 4f * p2.Y - p3.Y) * t2 + (-p0.Y + 3f * p1.Y - 3f * p2.Y + p3.Y) * t3); output.Add(new PointF(x, y)); } } output.Add(points[points.Count - 1]); // 补上最后一个原始点 return output; }

samplesPerSegment建议从 4 开始调。这个值决定两个原始采样点之间插入几个中间点，值越大画面越顺滑，但 GDI+ 需要绘制的线段数量也越多，低配机器会掉帧。一个经验值：普通手写输入场景 4~6 足够，要出“毛笔拖尾”效果可以调到 8 以上，但此时要和笔锋宽度计算配合好，因为宽度是逐点设置的，中间点增多后宽度变化更连续。

4.4 与笔锋算法串联：先平滑还是先算宽？

我的建议是先跑滑动窗口平均，再做宽度计算，最后做 Catmull-Rom 插值。原因很简单：宽度计算的输入是“点速度”，如果先插值再算宽度，插出来的中间点距离是人为加密过的，速度值全部被拉低，笔锋变化会失真。反过来，先平滑再算宽，速度曲线保留了原始书写节奏，算出来的宽度更符合直觉。

5. 编译运行与集成边界：从 Demo 变成能用的功能

5.1 在 Visual Studio 里编译运行

用 Visual Studio 打开test.sln后直接按 F5 是理想情况，但实际上最容易撞上的坑有两个：第一，项目目标框架如果标的是v4.x而本机只装了 .NET 6/8 运行库，会提示重新选择框架；第二，如果提示System.Drawing.Common缺失，需要在 NuGet 里搜同名的包装上。

# 用 msbuild 命令行编译（已安装 VS Build Tools 的情况下） msbuild test.sln /p:Configuration=Debug /p:Platform="Any CPU"

编译成功后bin\Debug目录下会生成test.exe。运行后窗口打开，用鼠标在画布上拖动，应该能看到带笔锋宽窄变化的墨迹轨迹。如果没有笔画显示，第一步先检查Global.cs里画布尺寸和Form1.cs里DoubleBuffered属性是否开启——不开启双缓冲时，笔画重绘会闪烁，但不会完全不显示；完全不显示，基本可以断定Paint事件没有订阅成功或者Graphics.DrawLine的Pen宽度传了非法值（如 NaN 或负值）。

5.2 在 WinForms 里把这段算法接进真实项目

真实项目不会用 Form1 里那一套“鼠标事件 + Paint 重绘”的写法裸奔，一般会抽出一个渲染层。常见做法是把笔画生成逻辑封装到独立的类中，业务层只管采集点、调用算法、扔给渲染层绘制：

public class CalligraphyRenderer { private List<StrokePoint> _strokePoints = new List<StrokePoint>(); private SmoothFilter _smoother = new SmoothFilter(); private BrushStrokeGenerator _generator = new BrushStrokeGenerator(); public void OnMouseMove(PointF current) { _strokePoints.Add(new StrokePoint { Position = current, Width = _generator.CalculateWidth(_strokePoints) }); // 做一次平滑后再渲染，保证 UI 线程响应 var smoothed = _smoother.Smooth(_strokePoints); var rendered = _generator.ApplyTaper(smoothed, 6); RenderToCanvas(rendered); } private void RenderToCanvas(List<StrokePoint> points) { using (var path = BuildOutlinePath(points)) { // 填充路径比逐段画线更接近毛笔质感 // 因为毛笔的墨迹是“面”不是“线” } } }

注意StrokePoint是一个自定义结构体，里面至少包含Position、Width、Pressure三个字段。Pressure现阶段可以默认置为 -1，后续接到真实手写板时，直接在CalculateWidth里把压力值作为权重乘进去就行。代码里的BuildOutlinePath是整条笔画的轮廓构建方法，这里需要把每个宽度不同的采样点展开成上下两个边界点，再拼成封闭多边形填充——这是从“画线”升级到“画毛笔字”的关键一步，但代价是计算量翻倍。

5.3 性能边界与触发条件

这套源码本质是 CPU 逐帧计算，笔画重绘性能与三个变量直接挂钩：历史点总量、插值密度、以及每帧是否全量重绘。当单条笔画采样点超过 2000 个、samplesPerSegment大于 8 时，低端 CPU 上会出现明显卡顿。

遇到性能问题先看这三个值，而不是急着优化绘制代码。大多数情况下，把窗口设置为双缓冲、限制历史笔画的保留数量，就能恢复流畅体验。

6. 避坑与常见问题：GDI+ 绘制的五个经典翻车点

6.1 笔画撕裂：同时处理多个笔画时缺少分层

现象：写完一个字的多个笔画，拖动窗口时笔画重叠区域出现凌乱的交叉线条，有些笔画还显示在其他笔画上层，顺序混乱。 原因：多个笔画没有按“先写先绘制”的顺序管理，重绘时重复调用了Graphics.DrawLine或FillPath，导致同一位置叠加了多次。 解决：定义一个笔画列表（List<Stroke>），在Paint事件里按列表顺序一次性绘制。新增笔画时只把新的Stroke加入列表，并不直接触发局部绘制，而是在每次Paint发生时全量渲染列表。

6.2 笔锋在快速书写时消失：平滑窗口太大

现象：拖着鼠标快速划一条斜线，起笔和收笔的尖峰效果看不出来，整条线像圆头马克笔。 原因：滑动窗口平均值太大，把快速采样点的速度信息抹平了；速度全部趋中，宽度也就全趋中。 解决：把SmoothPoints的windowSize从默认 7 降到 3，或者只对纵向坐标做平滑，不对横向坐标做平滑。后者能保留横向速度变化，笔锋宽窄恢复明显。

6.3 编辑 exe 图标报错“Resources 文件缺失”

现象：直接把test.exe复制到其他机器上运行，提示找不到资源或直接崩溃。 原因：Resources.resx中引用的图片资源没有作为Embedded Resource编译进程序集，或者在发布时没有勾选“预编译”选项。 解决：在test.csproj中找到对应资源项，把Copy to Output Directory改为Copy if newer；在Properties\Resources.Designer.cs里检查资源访问器是否与resx匹配，不匹配就删掉重新添加。

6.4 高 DPI 屏幕上坐标偏移：鼠标点和笔迹对不上

现象：在 125% 或 150% 缩放的 Windows 上运行，落笔位置和显示位置错位，偏右下或左上。 原因：WinForms 默认没有开启 DPI 感知，系统把坐标做了缩放后，MouseEventArgs的坐标与画布的实际像素不一致。 解决：在Program.cs入口处或App.config加一段 DPI 声明：

static class Program { [STAThread] static void Main() { if (Environment.OSVersion.Version.Major >= 6) { SetProcessDPIAware(); } Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } [System.Runtime.InteropServices.DllImport("user32.dll")] private static extern bool SetProcessDPIAware(); }

这段代码让进程感知真实 DPI，鼠标坐标不再被系统二次缩放。注意在 Windows 7 以下系统会返回 false，但不会造成崩溃，可以忽略返回值。

6.5 笔画的颜色晕染效果出不来：Graphics 对象配置被覆盖

现象：明明设置了Pen.Color的透明度（Alpha 值小于 255），画出来的颜色却毫无透明感，像纯黑。 原因：Form1.cs里某个地方对Graphics对象调用了SetParameters或重新赋值，覆盖了CompositingMode设置；另外双层缓冲开启时，透明色必须画在BufferedGraphicsContext上才生效。 解决：在每次绘制前统一设置渲染参数，不要分散在多个事件里：

Graphics g = e.Graphics; g.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias; g.CompositingMode = System.Drawing.Drawing2D.CompositingMode.SourceOver; g.PixelOffsetMode = System.Drawing.Drawing2D.PixelOffsetMode.HighQuality;

7. 把这些算法延伸成可复用的流畅笔刷工具：轮廓重建与性能优化实战

7.1 从“逐段画线”到“填充轮廓”的升级

前面几章的实现逻辑是每段线段用不同宽度的Pen去画，最终效果是中心线可见，但笔画边缘的真实毛笔质感——例如超出中心线范围的墨水洇染感——必须靠“面”来表现。升级思路是：对每个采样点，取法向方向正负偏移半个笔宽，得到上下两个轮廓点，然后把所有轮廓点连成一个封闭多边形：

public List<PointF> BuildOutline(List<StrokePoint> points) { List<PointF> upper = new List<PointF>(); List<PointF> lower = new List<PointF>(); for (int i = 0; i < points.Count; i++) { PointF pos = points[i].Position; PointF dir = GetDirection(points, i); // 当前点的切线方向 float nx = -dir.Y; float ny = dir.X; // 法向 float halfWidth = points[i].Width / 2f; upper.Add(new PointF(pos.X + nx * halfWidth, pos.Y + ny * halfWidth)); lower.Add(new PointF(pos.X - nx * halfWidth, pos.Y - ny * halfWidth)); } // 上边界正向，下边界反向，拼成一个封闭环 List<PointF> outline = new List<PointF>(upper); lower.Reverse(); outline.AddRange(lower); return outline; }

升级后的麻烦是：笔画交叉处会存在遮挡关系——后写的笔画不应该覆盖先写笔画的墨迹，但在同一个封闭多边形中必然覆盖。解决方式是在渲染层额外维护每个笔画的绘制顺序索引，按时间戳递增绘制。GDI+ 的FillPath是按调用顺序覆盖的，所以只要按时间顺序调用FillPath即可。

7.2 离线渲染与实时绘制的取舍

这套源码默认是逐帧实时渲染，但用于输出高清书法作品时，实时渲染的质感远不如离线渲染。实际工程中我会在MouseUp后触发一次“精细重绘”：

private void OnMouseUp(object sender, MouseEventArgs e) { _isDrawing = false; RenderHighQualityStroke(_currentStrokeId); // 将当前笔画的光栅化结果存入位图缓存 // 后续的交互笔画绘制使用一个更轻量的临时图层 // 这样既保持实时反馈，又保证最终作品质量 }

核心思路是“双图层”：交互层实时重绘，粗线条只需保证位置和笔锋方向大致正确；提交层在抬笔瞬间做一次高密度插值和抗锯齿填充。

7.3 扩展为可交互的调参面板

算法写好后的体验优化还需要交互调参，我把关键参数集中到一个AlgorithmOptions对象里：

public class AlgorithmOptions { public int SmoothWindowSize { get; set; } = 3; public int CatmullRomSamples { get; set; } = 5; public int TaperCount { get; set; } = 6; public float MinWidthFactor { get; set; } = 0.2f; public float MaxWidthFactor { get; set; } = 1.4f; public float TurnBoostAngle { get; set; } = 0.5f; public float TurnBoostWeight { get; set; } = 1.3f; }

UI 上放几个 TrackBar，拖动时实时更新这个对象。这样做的好处是换参不用反复改代码重新编译，算法跑得多了，你会发现“平滑窗口 3、插值密度 5、收笔 6”几乎是一套通用默认值——但每个笔迹库适合的参数组合又都不一样，调参面板是刚需的。从那以后我给任何笔迹算法做集成，第一步都是先把参数面板怼上去，再谈渲染效果——这能省下至少一半调参时间。希望这篇拆解能帮你在自己的项目里把毛笔字笔锋做成真正能用的模块。

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