WebKit 切换到 Skia 进行 2D 图形渲染
WebKit 的 GTK 和 WPE 端口正在用 Google 的 Skia 引擎替换 Cairo 图形库，以便在 Linux 和嵌入式设备上获得显著的性能提升并更好地利用 GPU。评论者指出，这一变化不会影响 Apple 的 Safari，后者仍然使用 Core Graphics，并强调 Igalia 在维护这些非 Apple 的 WebKit 端口中发挥的核心作用。这一变动也引发了对 Skia 与 Blend2D、Vello 和 Flutter 的 Impeller 等替代方案的更广泛比较，并带来了关于构建复杂度、API 稳定性、许可和长期维护的权衡问题。
Skia 迁移的范围
- 这一变更适用于 WebKitGTK 和 WPEWebKit 端口，不适用于 Apple 的 macOS/iOS WebKit。
- 文章标题后来做了澄清；评论者反复强调这不是 Safari。
- WPE 面向嵌入式 / 机顶盒式设备；WebKitGTK 为 GNOME 的浏览器和一些应用的 webview 提供支持。
动机与被认为的收益
- 这些端口当前的技术栈是 Cairo + 以 CPU 为中心的架构。
- 在桌面端使用 Skia 的内部测试即使在尚未进行认真优化前，MotionMark 分数也翻倍了。
- 评论者预计会有更好的性能，以及更现代、GPU 加速的管线。
- 一些人很高兴 Skia 使用的是与 GPL 兼容的 BSD 风格许可证。
Cairo 的局限性
- Cairo 被描述为实际上只处于维护状态，活跃开发者很少。
- GPU 后端（例如 OpenGL）已被移除，因为表现不佳且缺少维护者。
- 其架构以 PostScript 为模型：质量好、API 简单，但很难重定向到 GPU，而且在某些边角情况下速度很慢。
- 许多项目正在远离 Cairo，或正在脱离它的快速路径。
Skia 的优势与生态
- 使用广泛：Chrome、Android、Firefox Canvas、Flutter（历史上）、.NET、JetBrains UI，以及各种图形工具和框架。
- API 模型：排队绘制命令，进行优化，然后高效地渲染瓦片或区域。
- 给一些项目带来“渲染效果与 Chrome 一致”的强保证。
担忧：构建、API 稳定性与 C 接口
- 多个报告称 Skia 很难构建：需要自定义工具、依赖繁重、需求变化、构建缓慢或脆弱。
- 也有人说，只要按说明操作，当前的 Bazel/GN 构建其实很快。
- 有人抱怨 C++ API 持续变化，以及此前尝试的 C API 被移除。
- 有些人希望 WebKit 公开或帮助稳定一个 C API；另一些人则认为 Skia 应该保持为内部实现细节。
替代方案与更广泛的 2D 生态
- 提到的替代方案包括：Blend2D、AGG、NanoVG、Vello、thorvg、BGFX、The-Forge、AmanithVG/SVG、Qt 的 QPainter 和 GSK、Impeller、自定义引擎。
- Blend2D 的作者主张使用快速的纯 CPU 渲染和稳定的 C ABI，作为 Cairo/AGG 的继任者。
- 一些人怀疑 GPU 并不总是 2D 的正确答案；另一些人强调 GPU 现在已经是浏览器中的标准配置。