改进 Wayland 上的光标渲染

原文 ↗ Hacker News 讨论 ↗

存储、体积与“浪费空间”

  • 有人认为，XCursor 主题在磁盘上占用数 MB 在“TB 时代”并不重要，压缩还能进一步缓解。
  • 也有人反驳说，安装镜像和 Live 媒体仍然有很紧的体积预算，所以臃肿问题依然重要。
  • 这背后还有更广泛的张力：一边是“不要在微优化上浪费精力”，另一边是“死于无数低效之中”；文中把操作系统和游戏的臃肿都当作警示。

Wayland 的光标模型 vs X

  • 原始的 Wayland 设计是由客户端提供光标表面，合成器只负责把它们合成出来。
  • 批评者认为，普通应用居然要自己处理主题、尺寸和渲染，而不是只请求一种标准光标类型，这很“疯狂”。
  • 较新的 wp_cursor_shape 协议允许客户端请求命名的光标形状，被认为对大多数应用更合适，同时仍允许游戏和拖放场景使用自定义光标。

GTK/GNOME 与协议采用

  • 讨论提到 GTK 是 wp_cursor_shape 的“钉子户”，不过确实已经有问题和 MR。
  • 有人认为 GNOME 经常阻挡或拖延 Wayland 扩展；也有人说，达成共识的过程本来就慢但必要，而且 GNOME 并没有正式的否决权。

Hyprcursor 格式与采用顾虑

  • 来自 Hyprland 生态的 Hyprcursor 被宣传为一种更优、更现代、支持矢量的光标格式。
  • 顾虑包括：依赖专有的配置语言（Hyprlang）、跨桌面吸引力下降，以及可能再出现一个不兼容的光标标准。
  • 建议包括：使用通用配置格式（例如 XDG 风格的 INI）、发布规范，以及为现有 XCursor API 提供兼容层。

矢量 vs 光栅，以及 SVG 之争

  • 很多人喜欢矢量光标在高 DPI 下的思路，但担心完整 SVG 过于“杀鸡用牛刀”：复杂、依赖沉重，甚至还带脚本支持。
  • 也有人主张使用更简单的专用矢量格式（例如引用 Haiku 的图标格式），或者受限的 SVG 子集。

更广泛的 Wayland 设计与治理问题

  • Wayland 的“核心尽量小，其余全部作为扩展”在理论上受到赞赏，但当各个合成器无法就扩展达成一致时，也会造成碎片化，因而受到批评。
  • 关于客户端侧装饰 vs 服务端侧装饰的争论反复出现，争点涉及同步、VRAM 占用和 UI 一致性。
  • 文中还出现了关于企业（尤其是企业级厂商）影响力的猜测，但也有人反驳阴谋论，强调贡献者来源多样以及现实的技术约束。

其他

  • 有人提出需要诸如颜色反转光标之类的功能，并提到过去曾有专利顾虑，但相关专利很可能已经过期。
  • 也有人评论说，这一切感觉像是在重新解决长期存在的 Xorg 问题，而不是在其基础上继续推进。