GTK 的新渲染器

原文 ↗ Hacker News 讨论 ↗

GTK 新的 GPU 驱动渲染器引发了兴奋与怀疑并存的讨论。许多人欢迎期待已久的功能，例如正确的分数缩放、更好的颜色处理，以及主线程外渲染的潜力；而另一些人则担心在老旧硬件上的性能回退。评论者将 GTK 的架构演进与 Qt、游戏引擎以及像 Broadway 这样的基于 Web 的方案进行对比，围绕正确性、速度、可访问性和文本渲染的权衡展开争论。线程还进一步延伸到生态治理与资金问题，认为尖端图形技术与开源桌面工具包之间的差距，在很大程度上同资源和优先级有关，而不仅仅是技术难度。

Broadway 和“浏览器中的 GTK”

  • 多条评论提到 Broadway，这是 GTK 的 Web 后端，会把应用渲染到 HTML5 canvas 中。
  • 它被称赞为“手工艺品式的”，并且仍被用于 Cambalache 等工具，以及基于 Docker 的“浏览器中的 GUI”方案。
  • 也有人强调它并不是真正的 HTML UI：它像 VNC 一样传输像素，在滚动、文本输入、链接处理和可访问性方面都不理想。
  • 讨论还将它与真正的 Web UI（例如 qBittorrent 的）以及更新的 Wayland-in-browser 实验进行了比较与对比。

声明式 / 语义化 UI 和 TUI

  • 一些人希望有一种完全语义化、高层次的 UI 描述（如“列表-详情视图”“CRUD 编辑器”），它能自动映射为原生控件，也能生成终端 UI。
  • 现有系统如 XAML、SwiftUI、QML 被认为过于绑定表现层（矩形、边距），而不是纯粹的结构。

新的 GTK 渲染器与分数缩放

  • 大家对像素级精准的分数缩放以及统一的 Vulkan/GL 渲染器感到兴奋，这被视为长期以来急需的、与 Qt 和其他平台的对等能力。
  • 不同叙事相互冲突：
    • 批评者说 GTK/GNOME 领导层长期阻止分数缩放和文件选择器缩略图之类的功能，却称它们“不可实现”。
    • 其他人反驳说，这些功能需要对底层后端做深度重构、弃用旧方案，并照顾下游；所谓“不可实现”其实是“用旧架构不可行”。
  • 从技术上看，渲染现在是在最终缩放分辨率下完成，而不是先按 2× 渲染再由合成器下采样。

性能权衡

  • 一些使用老旧硬件的用户担心性能回退，并希望这些功能可以关闭。
  • 有观察指出，Vulkan 渲染器目前只是与旧 GL 性能持平，还没有更好；有人怀疑瓶颈在更高层。
  • 支持者强调，收益不只是原始速度：颜色准确性（包括 HDR）、GPU 路径 / 字形渲染、主线程外渲染，以及未来的优化潜力。

游戏引擎 vs GUI 工具包与资金

  • 有人提出，游戏图形开发者“领先了好几代”，但负担不起为 FOSS 工作；其他人认为这不现实，甚至像勒索。
  • 也有强烈反驳：GUI 渲染器必须处理文字排版、可访问性、打印、PDF/SVG、操作系统集成——这些需求通常是游戏引擎不管的。
  • 更广泛的反思认为，大量 FOSS 工作本来就有人付费（例如由厂商出资），而开源往往依赖特权、公共资金或协调一致的赞助。

X11、Wayland 与桌面打磨度

  • 一些人把 Linux 桌面的滞后归咎于 X11 客户端/服务器的历史包袱；也有人认为 X 很成功，而 Wayland 花了很多年，至今仍有缺口。
  • 第一手报告称，现代 Wayland 感觉更顺滑、更灵敏，也更安全（无撕裂、更好的合成、更安全的锁屏）。
  • 讨论还比较了 GNOME、KDE 和其他桌面环境在“打磨度”与可配置性之间的差异，并争论 Windows/macOS 的 DPI 处理。

UI 设计抱怨

  • 有人不喜欢把小部件放在标题栏里：拖拽区域不一致、标题空间更少，并且认为这是一种 GNOME/GTK 的趋势（不过也有人把功劳归于 Chrome）。

GPU 的职责

  • 有个简短问题问为什么 GPU 不“直接负责”缩放 / 抗锯齿；回答是 GPU 是低层的，所以工具包必须管理策略和渲染细节。