Ratty 终端模拟器：内联 3D 渲染管线与终端缓冲区融合架构

当我们谈论终端模拟器的进化时，大多数讨论集中在渲染性能的提升：Alacritty 的 Vulkan 路径、WezTerm 的 GPU 多路复用、Kitty 的动态字体缓存。然而 Ratty 选择了一条完全不同的路 —— 它不满足于「更快的文本渲染」，而是追问一个更根本的问题：终端本身能否成为一个 3D 画布？

这个问题的答案藏在 Ratty 的架构设计里：它将终端状态管理与 3D 渲染完全解耦，用一条精心设计的数据流水线让两者无缝融合。本文从系统层视角，剖析 Ratty 如何在不破坏终端语义的前提下，把整个终端嵌入到一个可自由变换的 3D 场景中。

架构总览：三段式渲染流水线

Ratty 的渲染管线可以被清晰地划分为三个阶段，每个阶段职责明确，通过标准化的数据接口串联。

第一阶段：终端状态管理。 应用程序或 Shell 运行在由 portable-pty crate 创建的伪终端（PTY）中，VT100/ANSI 转义序列通过 vt100 crate 被解析，从而维护一份完整的终端屏幕状态。这份状态包含字符内容、光标位置、样式属性以及终端尺寸信息。与传统终端模拟器（如 xterm、GNOME Terminal）不同，Ratty 在此阶段并不直接输出像素，而是输出一份结构化的终端缓冲区。

第二阶段：GPU 纹理合成。 Ratatui 从终端状态构建出一个终端缓冲区，并借助 parley_ratatui crate 将其渲染为 GPU 纹理。parley 负责字体管理、字形塑形等文本处理工作，而真正的 GPU 渲染则由 Vello 完成 —— 这是一个专门针对矢量图形优化的 GPU 渲染器，能够高效地将终端缓冲区中的每个单元格渲染为纹理图素（texel）。此阶段的输出是一个代表完整终端屏幕的 GPU 纹理，尺寸精确匹配终端列数乘以单元格宽度和行数乘以单元格高度。

第三阶段：3D 场景合成。 Bevy 引擎接过 GPU 纹理，将其作为材质贴图渲染到一个 3D 平面（或任意 3D 物体表面）上。在这个阶段，终端不再是一个平面矩形窗口，而是 3D 场景中的一个可渲染对象。开发者可以在此添加相机动画、灯光效果、额外的 3D 模型、阴影投射，以及任何 Bevy 生态系统中可用的渲染特性。终端纹理与这些 3D 元素共同构成最终画面。

这条流水线的核心设计哲学是关注点分离：终端仿真逻辑（PTY I/O 与转义序列解析）与表现层（GPU 纹理生成与 3D 渲染）完全解耦。两者之间仅通过终端缓冲区这一中间表示进行通信，这使得 Ratty 能够在保持对传统 Shell 和命令行工具完全兼容的同时，实现激进的视觉实验。

终端纹理生成：Ratatui 的缓冲区到 GPU 路径

理解 Ratty 的关键技术细节，需要深入其第二阶段的实现。Ratty 并不是从零实现终端渲染逻辑，而是复用了 Ratatui—— 一个为构建终端用户界面（TUI）而生的库 —— 作为其终端渲染层。

Ratatui 的核心抽象是 Buffer，它代表终端屏幕的像素级表示。每个终端单元格（cell）包含字符、前景色、背景色和样式信息。Ratty 将 vt100 crate 解析出的终端状态转化为 Ratatui 的 Buffer，然后调用 Ratatui 的渲染路径将 Buffer 绘制到一个帧缓冲（framebuffer）上。这个帧缓冲的内容随后被上传为 GPU 纹理。

关键在于 parley 与 Vello 的协作：parley 处理 Unicode 文本塑形、字体回退链解析和字形定位；Vello 则接收已塑形的字形数据，利用 GPU 并行能力将每个字形渲染到对应的终端单元格位置。由于 Ratty 需要在 GPU 上进行后续的 3D 处理，纹理生成阶段必须确保输出纹素的精确性和可寻址性 —— 每个终端单元格对应纹理中的一个矩形区域，这个映射关系在第三阶段会被反向使用，用于将 3D 对象锚定到终端单元格坐标。

3D 场景锚定：单元格坐标到世界空间

Ratty 最引人入胜的特性之一是能够将 3D 对象锚定到特定的终端单元格。当锚点单元格移动时（比如用户滚动或程序重绘），3D 对象会跟随移动。这背后的计算逻辑清晰而直接：

开发者首先获取终端尺寸（列数和行数）和视口尺寸（像素），通过两者的比值计算每个单元格的像素宽高。假设视口宽度为 viewport_size.x，终端宽度为 cols 列，则单元格宽度为 viewport_size.x / cols。类似地计算单元格高度。有了这些基础数据，就能在世界空间中定位任意单元格中心：x 坐标从视口左边界向内偏移，y 坐标从视口顶部向内偏移（注意 y 轴方向需根据渲染坐标系调整）。

以旋转光标为例：Ratty 首先从 Ratatui 端查询当前光标所在的行列号，然后在 Bevy 端查找或创建一个代表光标的 3D 实体（默认是一个旋转的老鼠模型），将该实体的位置设置为光标单元格对应的世界坐标，并施加旋转和上下浮动动画。动画参数完全独立于终端状态 —— 光标可以每分钟旋转 3 圈，同时上下浮动 15% 单元格高度 —— 但其位置始终严格跟随终端状态。

这种「终端单元格作为 3D 锚点」的模型，使得应用程序能够以极低的心智负担在终端中嵌入 3D 内容。应用程序只需知道要显示 3D 内容的单元格位置，剩下的 3D 渲染工作全部交给 Ratty 处理。

RGP 协议：扩展终端的图形能力

为了标准化应用程序与 Ratty 之间的 3D 对象通信，Ratty 定义了 Ratty Graphics Protocol（RGP）。这个协议的核心抽象是：应用程序注册一个 3D 资产，然后在终端单元格空间中放置该资产，Ratty 负责将其渲染为场景的一部分。

RGP 消息通过 APC（Application Program Command，控制序列之一）封装传输，格式为 ESC _ ratty;g;<verb> [; <key=value> ...] ESC \。当前 RGP 定义了四个动词操作：

• s：支持查询。应用程序发送此消息询问终端是否支持 RGP，Ratty 会响应其支持的协议版本和特性列表（如支持的对象格式、动画能力、深度测试、颜色和亮度控制等）。
• r：资产注册。应用程序注册一个新的 3D 模型文件（如 OBJ 或 GLB 格式），并分配一个唯一标识符供后续引用。
• p：对象放置。将已注册的资产锚定到指定的终端行列，指定其在终端中的尺寸（以单元格为单位），以及可选的动画、缩放、深度偏移、颜色和亮度参数。
• d：对象删除。移除指定标识符的已放置对象。

这个协议的设计目标是简单性和可扩展性。应用程序不需要了解 Ratty 内部的 3D 渲染细节，只需按照协议格式发送转义序列即可。例如，应用程序想要在第 5 行第 10 列放置一个动画的蓝色 3D 模型，只需发送两条转义序列 —— 一条注册资产，一条放置资产 ——Ratty 会自动完成剩下的工作。

对于已经使用 Ratatui 构建的应用程序，ratatui-ratty crate 提供了更高层的抽象。它定义了一个 RattyGraphic 结构体和 RattyGraphicSettings 配置结构，应用程序只需声明性地描述图形设置（模型路径、缩放、颜色等），然后将其实例化为一个 Ratatui Widget 渲染到目标区域。Widget 的 render 方法并非直接绘制像素，而是向 stdout 写入对应的 RGP 消息字符串，交由 Ratty 解释执行。

与 TempleOS 的渊源：命令行即文档

Ratty 的设计灵感明确来源于 TempleOS—— 一个由 Terry A. Davis 独自开发的奇特操作系统。TempleOS 最具标志性的特性是它的命令行（称为「命令 shell」）实际上是一个文档编辑器，支持在命令行中直接嵌入精灵图（sprite）和 3D 网格。开发者可以在编写游戏代码的同时，在同一份源文件中插入模型数据并在命令行中预览。

Ratty 试图将这种「命令行即画布」的理念移植到现代 Unix 终端环境中。但与 TempleOS 不同的是，Ratty 选择与现有终端生态兼容而非另起炉灶。TempleOS 是一个完整的操作系统，拥有自己的文件格式（DolDoc）、编程语言（HolyC）和图形系统；Ratty 则是一个运行在现有操作系统之上的终端模拟器，依赖标准 PTY 接口与 Shell 通信。这意味着 Ratty 能够无缝运行 Vim、tmux、git 等现有工具，同时为那些想要利用其图形能力的应用程序提供新的可能性。

在 Ratty 的文档演示中，开发者展示了从 TempleOS 源代码中提取的 3D 模型 —— 这些模型原本以压缩的二进制格式嵌入在 DolDoc 文档的追加区域中，需要解析 NUL 终止符、遍历 CDocBin 记录头、提取原始 CSprite 字节流并解码为 OBJ 几何数据。提取后的模型可以直接在 Ratty 中渲染，实现了跨越数十年、两种截然不同系统的技术连接。

工程权衡与资源代价

Ratty 的架构选择并非没有代价。由于 Bevy 游戏引擎是整个渲染管线的前端依赖，Ratty 的二进制大小和内存占用远超传统终端模拟器。开发者在官方 FAQ 中坦承这一点：运行 Ratty 意味着额外消耗约 300MB 内存，这主要用于维护 Bevy 的实体组件系统、纹理缓冲区和 3D 场景图。编译时需要拉取和构建数百个 Rust crate，这在首次安装时可能需要数分钟时间。

对于那些期望用 Ratty 替代日常主力终端的用户，开发者明确表示这不是项目的设计目标。Ratty 是一个实验性项目，旨在探索「终端能够成为什么」这一概念，其价值在于启发性而非实用性。从这个角度看，资源消耗是实现其独特愿景所必须付出的代价 —— 用游戏引擎驱动终端渲染，必然带来游戏引擎的负担。

未来方向与生态潜力

Ratty 目前仍处于活跃开发阶段，RGP 协议也在持续演进中。开发者在官方文档中指出，协议的具体细节可能会随着实现经验积累而调整。当前的四操作模型（查询、注册、放置、删除）是否足够表达未来可能的应用场景，还需要通过实际使用案例来验证。

一个值得关注的生态发展方向是 ratatui-ratty Widget 的成熟。如果有更多 TUI 应用程序作者开始使用这个 Widget，RGP 有望从一个实验性协议演化为某种程度的「终端图形标准」—— 当然，这取决于其他终端模拟器是否愿意实现兼容的协议子集。考虑到 Ratty 的架构与主流终端模拟器（如 Kitty、WezTerm、Alacritty）差异巨大，这种兼容性短期内并不现实。但 Ratty 作为一种概念证明，已经为终端可视化的未来提供了一种可能的愿景。

资料来源

• Orhun's Blog, "Ratty: A terminal emulator with inline 3D graphics", https://blog.orhun.dev/introducing-ratty/
• Ratty GitHub Repository, https://github.com/orhun/ratty

systems