“修复” MacBook Neo 光标卡顿：每 10 秒记录屏幕 1 个像素

原文 ↗ Hacker News 讨论 ↗

对 Neo 光标 bug 的总体反应

  • 许多人认为光标卡顿是 UX 中的“原罪”：指针被描述为用户在电脑中的“化身”，所以卡顿会让整个系统感觉坏掉了。
  • 评论者将其与 1980 年代到 1990 年代的系统作负面对比，后者即使在弱得多的硬件上，光标也始终平滑可靠。
  • 一些人说这应该被视为一个关键的、会阻断发布的问题。

提出的每 1 像素记录修复

  • 这个脚本会周期性地记录一个像素，迫使 WindowServer 合成光标，而不是使用硬件覆盖层。
  • 有人称赞它是一个对极其烦人的问题来说侵入性很小、很实用的变通方案。
  • 也有人把它称作“糟糕”的治法，因为它会让 GPU 保持唤醒或强制额外的合成，并担心用户会在 Apple 修复真正 bug 很久之后还忘了它在运行。
  • 类似的“土办法修复”模式也出现在一些轶事里：定期运行脚本做哈希以阻止线圈啸叫、通过碰触文件来防止 USB 硬盘转入休眠等。

技术讨论：硬件光标 vs 软件光标

  • 几篇详细帖子解释了硬件光标（独立覆盖平面、位置寄存器）与软件光标（绘制到合成后的帧缓冲中）之间的区别。
  • 一种理论是：卡顿发生在硬件光标切换到软件光标的过程中，可能是因为在等待 GPU 命令队列或 fence 刷新。
  • 也有人认为现代合成器只是每一帧重新渲染各层；他们认为那种“在光标下保存/恢复”的旧说法已经过时。
  • 目前并不清楚 macOS 在 Neo 上究竟做了什么；评论者说，真正的答案需要驱动或 WindowServer 代码。

其他缓解方式与相关 bug

  • 轻微调整光标大小在历史上曾修复过一些 GPU/合成 bug；在 Neo 上，据说需要明显更大的尺寸，而且未必总能奏效。
  • 还提到了 macOS 上分离式全屏低功耗模式，称其曾是过去一些渲染故障的来源。

对比与更广泛的 Apple 评论

  • 一些 Linux 用户报告在高负载或特定配置下也会出现类似的光标卡顿；也有人说自己从未遇到过，因此其普遍性存在争议。
  • 多条评论感叹 Apple 的 UX 严谨度似乎在下降，认为 Neo 的低价加上可见的故障削弱了“它就是能用”的品牌形象。

支线话题

  • 简短跑题到 Swift 的 guard 语法及其优点。
  • 关于把 Swift 作为脚本语言并通过 shebang 使用的说明。
  • 一些轶事式恶作剧，以及对旧硬件和 UI 设计原则的怀旧讨论。