WebKit mudando para Skia para renderização gráfica 2D

Artigo original ↗ Discussão no Hacker News ↗

Os ports GTK e WPE do WebKit estão substituindo a biblioteca gráfica Cairo pelo mecanismo Skia do Google para renderização 2D, visando grandes ganhos de desempenho e melhor uso da GPU em Linux e dispositivos embarcados. Os comentadores observam que essa mudança não afeta o Safari da Apple, que continua usando Core Graphics, e destacam o papel central da Igalia na manutenção desses ports do WebKit que não são da Apple. A mudança provoca comparações mais amplas entre Skia e alternativas como Blend2D, Vello e Impeller do Flutter, levantando questões de trade-offs sobre complexidade de build, estabilidade de API, licenciamento e manutenção de longo prazo.

Escopo da migração para Skia

  • A mudança se aplica aos ports WebKitGTK e WPEWebKit, não ao WebKit da Apple no macOS/iOS.
  • O título do artigo foi posteriormente esclarecido; os comentadores enfatizam repetidamente que isto não é o Safari.
  • O WPE visa dispositivos embarcados / do tipo quiosque; o WebKitGTK alimenta o navegador do GNOME e algumas webviews de aplicativos.

Motivação e benefícios percebidos

  • A pilha atual para esses ports é Cairo + uma arquitetura centrada em CPU.
  • Testes internos com Skia em desktop dobraram as pontuações do MotionMark mesmo antes de qualquer otimização séria.
  • Comentadores esperam melhor desempenho e um pipeline acelerado por GPU mais moderno.
  • Alguns ficam satisfeitos porque o Skia usa uma licença no estilo BSD compatível com GPL.

Limitações do Cairo

  • O Cairo é descrito como praticamente apenas em manutenção, com poucos desenvolvedores ativos.
  • Backends de GPU (por exemplo, OpenGL) foram removidos porque apresentavam pior desempenho e faltavam mantenedores.
  • Arquitetura modelada no PostScript: boa qualidade e API simples, mas difícil de redirecionar para GPUs e com casos de borda lentos.
  • Muitos projetos estão migrando para longe do Cairo ou saindo de seu caminho rápido.

Forças do Skia e ecossistema

  • Amplamente usado: Chrome, Android, Firefox Canvas, Flutter (historicamente), .NET, UI da JetBrains, várias ferramentas e frameworks gráficos.
  • Modelo de API: enfileirar comandos de desenho, otimizar e então renderizar tiles ou regiões de forma eficiente.
  • Dá a alguns projetos uma forte garantia de “renderiza como o Chrome”.

Preocupações: build, estabilidade da API e interface C

  • Há vários relatos de que o Skia é difícil de compilar: ferramentas personalizadas, dependências pesadas, requisitos que mudam, builds lentos ou frágeis.
  • Outros dizem que os builds atuais com Bazel/GN são rápidos se as instruções forem seguidas.
  • Reclamações sobre APIs C++ que mudam constantemente e a remoção de uma tentativa anterior de API C.
  • Alguns gostariam que o WebKit expusesse ou ajudasse a estabilizar uma API C; outros argumentam que o Skia deve permanecer como detalhe de implementação interno.

Alternativas e panorama mais amplo de 2D

  • Alternativas mencionadas: Blend2D, AGG, NanoVG, Vello, thorvg, BGFX, The-Forge, AmanithVG/SVG, QPainter e GSK do Qt, Impeller, motores personalizados.
  • O autor do Blend2D defende renderização rápida apenas em CPU com uma ABI C estável como sucessor do Cairo/AGG.
  • Alguns são céticos de que GPU seja sempre a resposta certa para 2D; outros enfatizam que GPU agora é padrão em navegadores.