微控制器的 JIT 位图文本渲染

微控制器的 JIT 位图文本渲染 Raph Levien，2026 年 11 月 7 日 我一直在研究 vic-2350，它是 RP2350 微控制器板上 80 年代家用计算机的重新构想。当然，这样的项目需要文本渲染。尽管位图字体现在不再受欢迎，但我选择它们既是为了提高效率，也是因为在低分辨率下，我更喜欢清晰、有意设计的位图字体的美感，而不是模糊的抗锯齿字体渲染。他们仍然有一个利基市场，尽管是一个狭窄的市场。我还想要比例间距和字距调整，同样是因为我喜欢早期 Macintosh 及其前身的美感。 RP2350 项目中的大多数文本渲染都基于固定字符单元，因为实现良好的性能很棘手。这篇博文介绍了一种在 RP2350 等微控制器上极快速地渲染位图文本的技术。我已将其实现为我的 race-the-beam 渲染器的一部分，但在写入帧缓冲区时也可以使用相同的技术。核心思想是 JIT 动态生成高度优化的代码以呈现字符串。八十年代中期左右，计算机显示文本的方式发生了分裂。既定的技术是固定的单元尺寸，以及当图像被扫描到显示器时动态查找字体 ROM 中的字符的硬件。优点是在有限的硬件下非常快的更新和响应能力。许多终端都是这样工作的，家用电脑也是如此。缺点是缺乏灵活性。特别是，仅支持等宽字体。较新的技术是位图帧缓冲区，它是在 Xerox Alto 的一系列计算机上首创的，一直到 Apple Lisa，最后在 Macintosh 上流行起来。帧缓冲区更加灵活，但需要更多的计算能力来保持更新。在 80 年代初期，您通常会看到文本渐进式渲染。我还应该提到，图形模式通常在家用计算机上可用，但它们的分辨率通常低于文本模式，并且 1MHz 6502（或类似的）不够强大，因此基于文本的程序（例如文字处理器和电子表格）使用文本模式。快进到 RP2350。它能够在 HSTX 外设的帮助下输出 DVI 视频，但仍然完全取决于软件来填充视频缓冲区。有些项目选择帧缓冲区，但芯片上只有 520kB 的 SRAM，因此帧缓冲区必须在分辨率或位深度或两者上受到限制，并且该 RAM 可供应用程序用于其他用途也将是一件好事。我选择了与光束竞赛，在每个扫描线填充一个视频缓冲区。这允许更丰富的视觉效果和更低的延迟，但对渲染器来说是一个严格的性能限制。每个像素的预算约为 6 个周期。我们的预算越低，可用于渲染其他图形对象和其他应用程序功能的资源就越多。 Rust无法满足性能要求，所以我开始编写ARM汇编语言。渲染器以及 vic-2350 的大部分内容现在都是用 symbolasm 编写的，这是我为极高性能 Cortex-M33 编程而创建的一种编程语言。使用 JIT 可以进一步加快渲染速度。渲染管线 渲染通常被建模为管线，vic-2350 渲染器也不例外。应用程序和渲染器之间的接口是一个显示列表。从本质上讲，这就是它所说的，显示对象的列表。显示列表是双缓冲的；一个正在渲染和扫描，另一个由应用程序构建。在每次垂直同步时，如果应用程序准备就绪，则会交换显示列表。构建显示列表的计算量并不大，但当然应用程序可能正忙于做其他事情。由于显示列表在编译时大小未知，因此会进行分配。显示对象被打包成两个向量；一个保存显示对象本身，另一个保存第一个向量的索引列表。显示对象由 vtable、边界矩形和特定于对象的有效负载组成。分配是可以接受的，因为构建显示列表对时间要求不严格。渲染则是另一回事。也就是说，显示列表的内存效率非常重要，尤其是在有两个副本的情况下。在呈现之前，索引按 y0 升序排序。在渲染期间，渲染器维护一个活动列表，它只是与当前扫描线相交的显示对象的子集。在每个扫描行，y1 = y 的对象从活动列表中删除，并插入 y0 = y 的新对象，这就是排序较早的原因；这正是对象插入活动列表的顺序。活动列表按显示对象顺序保存。然后渲染器只为活动列表中的每个显示对象调用 render 方法。我很快就会做更多的优化，跟踪不透明的跨度