GTK：引入图形卸载
GTK 4.14 的新“图形卸载”功能旨在通过让某些内容（如视频）借助 Wayland subsurfaces 和 dmabufs 由 GPU 直接扫描输出，从而绕过通常的场景图合成，降低延迟和功耗。评论者将这种现代的零拷贝、硬件平面方案与更老的 X11 机制（Xv、overlays、DGA）作对比，讨论它为何目前仅限 Wayland 且偏向 Linux，以及类似思路如何映射到 macOS（IOSurface）和 Windows（DirectX shared handles）。讨论串还引出了 GTK 正在从通用跨平台工具包转向的更大张力、Wayland 与 X11 在安全性和能力上的取舍，甚至包括圆角窗口等设计选择如何让高效的直接扫描输出变得更复杂。
平台 / 操作系统支持
- 目前的图形卸载仅在 Linux 上的 Wayland 下、并且使用基于 dmabuf 的内容时可用。
- macOS 和 Windows 也有大致等价的原语（macOS 上的 IOSurface、Windows 上的 Direct3D shared handles），但 GTK 还没有把它们接上；维护者表示这“只是工作量”问题，时间是主要阻碍。
- Wayland 的 tearing-control 协议已经存在；一些人认为它还没有像 X11 的全局 TearFree 开关那样方便。
GTK 的方向与跨平台角色
- 一些评论者认为 GTK 正在变得越来越以 Linux/Wayland 为中心，作为跨平台“原生”工具包的可行性越来越差；有些应用已经转向 Qt。
- 另一些人则认为 GTK 一直主要是 Linux/X11 优先，而非 GNOME 环境过去对上游贡献很少，所以现在 GNOME 的需求正在定义路线图。
- 对于 GNOME 是“杀死”了一个操作系统中立的 GTK，还是仅仅让它演化了，存在分歧。
Wayland vs X11
- 支持者：Wayland 的设计（subsurfaces、dmabuf、overlay planes）让零拷贝 / 直接扫描输出相对直接且安全，而且基于合成器的渲染默认就消除了撕裂。
- 怀疑者：X11 早就有 Xv overlays、DGA 等概念，这感觉像是在“重新发明轮子”，不过也有人回应说，X 在合成环境下或对任意 GPU 格式时从未真正提供同样的能力。
- 安全性争论：一方强调 X11 在客户端之间缺乏基本隔离，以及其历史上长期存在可被利用的解析漏洞；另一方则声称这些问题对普通桌面用户来说大多只是理论上的。
图形卸载如何工作
- GTK 4 已经通过 GL 渲染到由 dmabuf 支撑的 GPU 纹理；卸载只是让 GTK 将子部件附加到 Wayland subsurface，这样合成器就可以把该缓冲区直接映射到硬件平面上。
- 好处：通过避免额外的合成工作，视频、摄像头和模拟器输出等场景的功耗以及 CPU/GPU 使用率更低。
- 几位开发者澄清，像素并不会拷回主内存；这全部都发生在 GPU 侧。
圆角与 UI 权衡
- 窗口圆角会干扰直接扫描输出，因为裁剪目前发生在客户端，而不是合成器。
- 变通方案包括 letterboxing（黑边），这样视频本身保持矩形，或者对卸载内容放弃圆角。
- 有些人认为圆角和重效果是不必要的性能税；另一些人则认为，只要开销适中，这些就是不可妥协的 UX 打磨。
合成器、延迟与撕裂
- 合成器可以实现效果（透明、缩放、概览）和无撕裂，但会增加延迟。
- 一些用户更喜欢撕裂和直接前缓冲写入，以获得文本编辑或游戏时更好的响应；另一些人则认为，考虑到人类反应时间和现代刷新率，相较于可见伪影，这点边际延迟收益很小。
- 对于日常编辑和编码里几十毫秒的延迟到底有多明显，大家意见不一。
生态协调与历史
- 多处提到 freedesktop/Wayland hackfest 和 Linux 大会，说明内核、合成器和工具包开发者已经在需求上进行协调。
- 有人将其与 BeOS/Haiku 和 SunView 相比，它们较早就有直接帧缓冲和共享缓冲模型；有人称赞其流畅性，但也指出它们缺乏当今所期待的功能、安全性以及以 GPU 为中心的设计。
OpenGL vs Vulkan 与 GTK 内部
- GTK 4 从即时模式的 Cairo/X11 假设转向了场景图（GSK）以及类 Wayland 的模型，这大大简化了后端，并为未来的线程化/分块渲染器等特性铺平了道路。
- 当前的加速渲染基于 GL 和 dmabuf；虽然有 Vulkan 渲染器，但成熟度较低，仍需要贡献者。
- 有人把 GL 称为相对 Vulkan 而言的“遗留臃肿”；另一些人则指出，GL 实现仍在维护中，而且对工具包来说依然实用。