把 Blender 的界面层拆出来做桌面 UI：BUI 说比 GPUI 快，先当 demo 看

作者：陈一帆

11月6日，开发者 ppmpreetham 在 HN 发布独立桌面 UI 运行时 BUI，把 Blender 的界面层拆出来复用，标题称"比 GPUI 快得多"，帖子 200 分、77 评论。本文解释即时模式与保留模式的区别，并把"快过 GPUI"当作作者自述、按个人 demo 定位，标出 benchmark、许可证、成熟度等未核实项。

11月6日，开发者 ppmpreetham 在 HN 发帖，把自己从 Blender 界面层拆出来的独立桌面 UI 运行时 BUI 摆上台面，标题直接写"Blender's UI and Runtime: Much Faster Than GPUI"。帖子拿到 200 分、77 条评论 。要说"变化"，目前只是多了一个开源实验仓库和一场讨论：BUI 还不是装来就能用的产品，"快过 GPUI"也只是作者写在标题里的自述。

按帖子指向的仓库，作者的思路是把 Blender 这套在 3D 交互里打磨多年的界面层单独抽出来，让普通桌面应用也能用 。至于具体怎么拆、暴露了哪些接口、benchmark 怎么测，这一轮我没能读到仓库原文，所以不替作者复述任何数字。

为什么一个 3D 软件的界面代码，有可能比专门做 UI 的框架快？用日常场景说：Blender 的界面像一块每帧都整面擦掉重写的白板——鼠标一动，面板连同 3D 视口整帧重画。它得在高帧率、大批量绘制的压力下保住建模时的顺滑手感，这条绘制路径是被高压场景常年磨出来的。而多数 UI 框架面对的是"点个按钮、改行文字"的轻负载，精力自然更多花在控件管理、动画、无障碍这些地方。目标不同，取舍就不同。

顺带分清两个词。即时模式 UI 每帧重新生成整个界面，状态捏在应用手里，好比每帧重新报一遍菜名；保留模式先把控件对象建好，再靠事件做局部更新，好比菜单挂在墙上，改哪条划哪条。前者省状态同步，后者省重绘。Zed 的 GPUI 其实两种思路都沾，所以"谁比谁快"必须先问清：比的是哪一步、测的什么负载——而这恰恰是最该核实、我却还没核实到的部分。

HN 那 200 分说明话题确实吸人；77 条评论里很可能有对测法可信度的追问，但我没读到评论原文，这里只记一句"讨论存在、内容未知"。

实际影响先别放大。个人实验项目，按 demo 定位比较合适。真正值得盯的有两点：一是许可证——Blender 本体是 GPL 系授权，从它拆出来的代码大概率同样受限（这是我基于常识的推断，仓库实际授权待核）；二是成熟度——文档、示例、平台支持都还是未知数。如果 benchmark 站得住，它给写编辑器、终端这类性能敏感应用的人提供了一条不太常规的思路；如果站不住，它也算一份不错的即时模式 UI 教学样本。这两种结局，我都乐见。

转载说明

本文根据以下公开资料整理，原文及配图出处见下方。

• [S1] Blender's UI and Runtime: Much Faster Than GPUI