为 Emacs 构建 GPU 后端：一次从极客好奇到架构重构的深度探索

背景

几个月前，一位开发者被一个看似荒谬的问题困扰：为什么在配备性能强劲 GPU 的笔记本电脑上，Emacs 仍然完全依赖 CPU 来渲染所有文本？这一疑问引发了一系列连锁反应：为什么不能在 Buffer（缓冲区）内播放视频？为什么不能实现动态的光标特效？为什么不能在 Buffer 切换时实现平滑的交叉淡入淡出效果？

为了回答这些问题，这位开发者决定深入挖掘 Emacs 的底层代码。他惊讶地发现，Emacs 的显示引擎（xdisp.c）诞生于没有 GPU 加速选项的时代，其设计完全针对 CPU 计算进行了毫米级的优化。在过去，几乎没有人能在不重写 Emacs 一半代码的情况下，将 GPU 引入渲染管线。

然而，随着现代图形 API 的发展，这一局面被打破。这位开发者决定尝试构建一个 GPU 后端。起初这只是一个周末的实验，最终却演变为一个完整的 macOS Metal 后端、一个 GNU/Linux OpenGL 后端，以及一个内置视频播放器和着色器光标特效的功能集。这一过程不仅在技术上取得了突破，还在 Emacs 开发者邮件列表上引发了关于 cairo 性能、软件自由以及人工智能伦理的激烈辩论。

值得注意的是，该项目从始至终是在大型语言模型（LLM）作为“副驾驶”的帮助下完成的。这一事实不仅是诚实的声明，更成为了整个旅程中最重要的转折点。

核心内容

第一阶段：架构决策——抽象与解耦

任何人的第一直觉可能是直接修改 macOS 的 Cocoa 后端（nsterm.m），将 CoreGraphics 调用替换为 Metal 调用。这是最直接的路径，但也是最具局限性的。如果这样做，得到的只是一个“带有 Metal 的 Mac 版 Emacs”，无法跨平台复用。

为了解决平台绑定问题，开发者设计了一个三层架构：

1. 核心层（Core）：保持 xdisp.c（重显引擎）完全 untouched（未修改）。它负责计算字符矩阵，逻辑与以往完全一致。
2. 策略层（Policy）：位于 src/gfxterm.c，使用纯 C 语言编写，制定中立的绘图策略。所有关于字符组合、下划线位置、图像裁剪和滚动逻辑都集中在此，不包含任何平台特定的代码。
3. 接口与驱动层（Interface & Driver）：通过 src/gfxdrv.h 定义约 25 个基本操作接口（如“上传纹理”、“绘制四边形”、“呈现帧”）。每个平台只需实现这个契约。

黄金法则：绝不触碰 xdisp.c。如果实验失败，Emacs 依然能正常工作。这一决策被证明是项目中最好的决定，因为它确保了兼容性和稳定性。

第二阶段：Metal 后端与像素级 parity（一致性）

在明确架构后，开发者开始攻克 Metal 后端。技术路线遵循现代文本渲染的标准流程：

• 通过 CoreText 将每个字形光栅化为灰度纹理（R8 格式的字符图集）。
• 作为带纹理的四边形绘制文本。
• 将图像（PNG, JPEG, SVG, GIF）上传为纹理。
• 在 GPU 上合成整个帧并呈现。

然而，理论上的“两个下午”变成了实践中的“数周”。核心挑战在于像素级一致性（Pixel Parity）。成功标准不是“看起来不错”，而是结果必须与原始 Cocoa 后端逐像素完全相同。

开发者构建了一个测试工具：同时启动两个 Emacs 实例，加载相同场景，捕获屏幕并使用 Python 和 PIL 进行对比。基线差异率约为 0.055%，任何超出此范围的差异都被视为 Bug。这一严苛的标准暴露了许多细微问题：

• 墨迹权重：CoreText 和着色器在抗锯齿处理上的差异。
• 浮雕颜色：按钮和模式行的 3D 边框渲染不正确。
• 垂直偏移：字形位置存在“差一错误”（off-by-one）。

由于绘图方式在架构和方法上完全不同，这些 Bug 极其隐蔽且难以检测。

第三阶段：冻结的光标与动画革命

在所有 Bug 中，光标问题教会了开发者最多。

为了实现炫酷的动画光标效果（如跳跃时扩散的圆环、彗星般的尾迹），开发者将其实现为帧上方的合成层。这些特效在打字时运行完美，但一旦停止输入，动画就会在半途冻结。

原因：Apple 的同步机制 CADisplayLink 在空闲时会停止工作。当没有用户输入时，Emacs 的事件循环不会向其提供数据，导致“时钟”停止。

解决方案：

1. 不再依赖系统同步机制，将所有连续动画移至 Lisp 定时器。
2. 光标、Buffer 交叉淡入淡出和视频播放均由 Emacs Lisp 中的单一“泵”驱动，定期 tick 并指示驱动“推进所有内容并呈现”。
3. 统一三个定时器，实现自动调速：淡入淡出时 60Hz，其他情况 30Hz，无动画时自动关闭。

至此，macOS 后端完成。除了基础的文本、装饰、图像、Retina 支持外，还实现了：

• Buffer 内的视频播放。
• 基于着色器的光标特效。
• Buffer 切换时的平滑交叉淡入淡出（仅多一次着色器传递）。

甚至，开发者还在 Emacs 内部构建了一个小型 YouTube 前端，直接在 Buffer 中搜索并播放视频，由 GPU 将帧合成在文本之上。

第四阶段：打包即半壁江山

让二进制文件在本地运行与让他人安装是两回事。这一阶段缺乏技术光环，却耗费了大量时间。

主要难点在于 Apple 的代码签名和公证（Notarization）流程：

• 这是一个复杂的迷宫。
• 当引入原生编译（native-comp，AOT 编译）后，出现了约 1564 个 .eln 文件。
• 这些文件也是 Mach-O 代码，必须逐个签名并添加安全时间戳，才能通过公证。

最终，开发者发布了第一个经过签名和公证的 Homebrew cask 版本，并开始日常使用。

关键要点

• 架构解耦是关键：通过保持 xdisp.c 不变，仅抽象出绘图接口（gfxdrv.h），实现了在不破坏 Emacs 核心逻辑的前提下引入 GPU 加速。这种“策略与实现分离”的设计使得跨平台支持（Metal 和 OpenGL）成为可能。
• 像素级一致性极具挑战性：GPU 渲染与 CPU 渲染在抗锯齿、颜色处理和坐标计算上存在细微差异。建立严格的自动化测试工具（Pixel Diff Harness）是确保用户体验无缝过渡的必要条件。
• 动画依赖事件循环：在 macOS 上，CADisplayLink 在无输入时会休眠。将动画逻辑从系统同步机制迁移到 Emacs Lisp 定时器，并实现自适应帧率（Auto-pacing），是解决动画冻结问题的核心方案。
• LLM 作为开发协作者：项目从始至终使用 LLM 作为 Copilot。这不仅提高了编码效率，也引发了关于 AI 在开源软件开发中伦理角色的讨论。
• 打包与分发成本高昂：在现代操作系统（特别是 macOS）上，代码签名、公证以及处理原生编译产生的大量二进制文件，构成了巨大的工程负担，往往被技术开发者低估。

意义与影响

1. 技术可行性验证

该项目证明了为 Emacs 构建 GPU 后端在技术上是完全可行的。它打破了“Emacs 无法利用现代硬件加速”的固有印象，展示了通过抽象层设计，古老代码库也能拥抱现代图形 API。

2. 用户体验的革新

引入 GPU 加速后，Emacs 获得了前所未有的视觉能力：

• 高性能多媒体：在 Buffer 内流畅播放视频和处理动画 GIF。
• 平滑视觉过渡：Buffer 切换时的交叉淡入淡出效果，提升了操作的流畅感。
• 个性化定制：基于着色器的动态光标效果，满足了极客用户对个性化界面的追求。

3. 对 Emacs 生态的启示

虽然该项目目前主要面向 macOS 和 GNU/Linux，但其架构设计为未来其他平台