Tudo pronto para a próxima geração de conteúdo da Web
O RenderingNG é uma arquitetura de renderização de última geração que supera em muito o que veio antes. O RenderingNG foi criado ao longo de mais de oito anos e representa o trabalho coletivo de muitos desenvolvedores dedicados do Chromium. Ele libera uma enorme quantidade de potencial para conteúdo da Web rápido, fluido, confiável, responsivo e interativo.
Aqui, você vai aprender o que criamos, por que criamos e como funciona.
Meta da estrela-guia
O objetivo principal que motiva o RenderingNG é que a implementação do mecanismo do navegador e a riqueza das APIs de renderização não sejam um fator limitante da UX na Web.
Não se preocupe com bugs do navegador que tornam os recursos não confiáveis ou que quebram a renderização do site.
Não deve haver um declínio misterioso de desempenho. E não é necessário contornar recursos integrados ausentes.
Ele deve funcionar.
O RenderingNG é um grande passo para essa meta. Antes do RenderingNG, podíamos adicionar e melhoramos os recursos de renderização, mas tivemos dificuldades para tornar esses recursos confiáveis para os desenvolvedores, e houve muitos declínios de desempenho. Agora temos uma arquitetura que resolve sistematicamente muitos desses problemas e também desbloqueia recursos avançados que não eram considerados viáveis antes. Ele:
- Tem recursos principais sólidos em diferentes combinações de plataforma, dispositivo e sistema operacional.
- Tem desempenho previsível e confiável.
- Maximiza o uso de recursos de hardware (núcleos, GPU, resolução da tela, taxas de atualização, APIs raster de baixo nível).
- Realiza apenas o trabalho necessário para exibir conteúdo visível.
- Tem suporte integrado para padrões comuns de design visual, animação e design de interação.
- Oferece APIs para desenvolvedores para gerenciar facilmente os custos de renderização.
- Fornece pontos de extensão de renderização do pipeline para complementos de desenvolvedor.
- Otimização de todo o conteúdo: HTML, CSS, tela 2D, tela 3D, imagens, vídeos e fontes.
Comparação com outros mecanismos de renderização do navegador
O Gecko e o WebKit também implementaram a maioria dos mesmos recursos de arquitetura descritos nessas postagens do blog e, em alguns casos, até os adicionaram antes do Chromium.
Qualquer navegador que fique mais rápido e confiável é motivo de comemoração e tem um impacto real. O objetivo final é avançar o valor de referência para todos os navegadores, para que os desenvolvedores possam confiar nele.
A pirâmide do sucesso
Minha filosofia é que o sucesso é o resultado de alcançar primeiro a confiabilidade, depois o desempenho escalonável e, por fim, a extensibilidade.
Assim como em uma pirâmide real, cada nível fornece uma base sólida para o nível acima.
Confiabilidade
Para que experiências de usuário ricas e complexas sejam possíveis, a primeira coisa que precisamos é uma plataforma sólida. Os recursos principais e as bases precisam funcionar corretamente e continuar funcionando ao longo do tempo. Além disso, é igualmente importante que esses recursos sejam bem compostos e não tenham comportamentos ou bugs estranhos.
Por isso, a confiabilidade é a parte mais importante do RenderingNG. E a confiabilidade é o resultado de bons testes, ciclos de feedback de qualidade, métricas e padrões de design de software.
Para ter uma ideia de como a confiabilidade é importante, passamos a maior parte dos últimos oito anos trabalhando apenas nessa parte. Primeiro, criamos um conhecimento profundo do sistema, aprendendo com relatórios de bugs onde estavam os pontos fracos e corrigindo-os, iniciando testes abrangentes e entendendo as necessidades de desempenho dos sites e as limitações do desempenho do Chromium. Em seguida, projetamos e lançamos cuidadosamente e de forma incremental os principais padrões de design e estruturas de dados. Só então estávamos prontos para adicionar primitivas de última geração para design responsivo, escalabilidade e personalização de renderização.
Isso não significa que nada foi melhorado nesse período no Chromium. Na verdade, o oposto é verdadeiro. Nesses anos, houve um aumento constante e sustentado na confiabilidade e no desempenho à medida que refatorizamos e lançamos cada melhoria passo a passo.
Testes e métricas
Nos últimos oito anos, adicionamos dezenas de milhares de testes de unidade, desempenho e integração. Além disso, desenvolvemos métricas abrangentes que medem muitos aspectos do comportamento da renderização do Chromium em testes locais, em comparativos de desempenho e em sites reais, com usuários e dispositivos reais.
Mas, por melhor que seja o RenderingNG (ou outro mecanismo de renderização de navegador), não será fácil desenvolver para a Web se houver muitos bugs ou diferenças de comportamento entre os navegadores. Para resolver esse problema, também maximizamos o uso dos Testes da plataforma da Web. Cada um desses testes verifica um padrão de uso da plataforma da Web que todos os navegadores precisam passar. Também monitoramos de perto as métricas para aprovar mais testes ao longo do tempo e aumentar a compatibilidade do núcleo.
Os testes da Web Platform são um esforço colaborativo. Por exemplo, os engenheiros do Chromium adicionaram apenas cerca de 10% do total de testes do WPT para recursos do CSS. Outros fornecedores de navegadores, colaboradores independentes e autores de especificações contribuem com o restante. É preciso de uma aldeia para criar a Web interoperável.
Bons padrões de design de software
Fornecer software de qualidade de maneira confiável é muito mais fácil se o código for fácil de entender e projetado de maneira que minimize a probabilidade de bugs. Vamos falar muito mais sobre o design de software do RenderingNG em posts de blog futuros.
Desempenho escalonável
Alcançar um ótimo desempenho nas dimensões de velocidade, memória e uso de energia é o próximo aspecto mais importante do RenderingNG. Queremos que as interações com todos os sites sejam suaves e responsivas, mas sem sacrificar a estabilidade do dispositivo.
Mas não queremos apenas performance, queremos performance escalonável, uma arquitetura que tenha bom desempenho em máquinas de baixo e alto custo, e em todas as plataformas de SO. Eu chamo isso de escalonamento, ou seja, aproveitar tudo o que o dispositivo de hardware pode alcançar e escalonar para baixo, maximizando a eficiência e reduzindo a demanda no sistema quando necessário.
Para chegar lá, precisamos usar ao máximo o armazenamento em cache, o isolamento de desempenho e a aceleração de hardware da GPU. Vamos considerar cada um deles por vez. Para tornar isso mais concreto, vamos pensar em como cada um deles contribui para o desempenho de uma interação extremamente importante nas páginas da Web: a rolagem.
Armazenamento em cache
Em uma plataforma de interface dinâmica e interativa, como a Web, o armazenamento em cache é a maneira mais importante de melhorar drasticamente o desempenho. O tipo mais conhecido de armazenamento em cache em um navegador é o cache HTTP, mas a renderização também tem muitos caches. O cache mais importante para rolagem são as texturas e listas de exibição em cache da GPU, que permitem que a rolagem seja extremamente rápida, minimizando o consumo de bateria e funcionando bem em vários dispositivos.
O armazenamento em cache ajuda a prolongar a vida útil da bateria e a taxa de frames da animação para rolagem, mas o mais importante é que ele desbloqueia o isolamento de desempenho da linha de execução principal.
Isolamento de desempenho
Em computadores modernos, você não precisa se preocupar com aplicativos em segundo plano que podem deixar o computador mais lento. Isso ocorre devido à multitarefa preventiva, que é uma forma de isolamento de desempenho: ela garante que tarefas independentes não diminuam a velocidade umas das outras.
Na Web, o melhor exemplo de isolamento de desempenho é a rolagem. Mesmo em sites com muito JavaScript lento, a rolagem pode ser muito suave, porque é executada em uma linha de execução diferente que não precisa depender da linha de execução do JavaScript e do layout. Fizemos um grande esforço no RenderingNG para garantir que todas as rolagens possíveis sejam encadeadas, usando o armazenamento em cache que vai muito além de uma lista de exibição para situações mais complexas. Os exemplos incluem código para representar elementos fixos e posicionados, listeners de eventos passivos e renderização de texto de alta qualidade.
Aceleração de GPU
Uma GPU torna a geração de pixels e a exibição na tela muito mais rápida. Em muitos casos, cada pixel pode ser exibido em paralelo com todos os outros, resultando em um enorme aumento de velocidade. Um componente importante do RenderingNG é o raster de GPU e o render em todos os lugares. Isso usa a GPU em todas as plataformas e dispositivos para acelerar a renderização e a animação do conteúdo da Web. Isso é especialmente importante em dispositivos de baixo custo ou muito sofisticados, que geralmente têm uma GPU muito mais capaz do que outras partes do dispositivo.
Extensibilidade: as ferramentas certas para o trabalho
Depois de alcançar a confiabilidade e o desempenho escalonável, estamos prontos para criar uma série de ferramentas para ajudar os desenvolvedores a estender as partes integradas de HTML, CSS e Canvas, de maneiras que não comprometam a confiabilidade e o desempenho conquistados com tanto esforço.
Isso inclui APIs integradas e expostas por JavaScript para casos de uso avançados de design responsivo, renderização progressiva, fluidez e capacidade de resposta e renderização em linha de execução.
As APIs da Web abertas a seguir, defendidas pelo Chromium, foram possibilitadas pelo RenderingNG e antes eram consideradas inviáveis.
Todos eles foram desenvolvidos com especificações abertas e colaboração com parceiros da Web aberta, engenheiros de outros navegadores, especialistas e desenvolvedores da Web. Em posts de blog futuros, vamos nos aprofundar em cada um deles e explicar como o RenderingNG os torna possíveis.
- content-visibility: permite que os sites evitem facilmente o trabalho de renderização para conteúdo fora da tela e a renderização em cache para visualizações de aplicativos de página única que não estão sendo mostradas no momento.
- OffscreenCanvas: permite que a renderização de tela (a API de tela 2D e o WebGL) seja executada na própria linha de execução para uma performance confiávelmente excelente. Esse projeto também é outro marco importante para a Web. É a primeira API da Web que permite que o JavaScript (ou o WebAssembly!) renderize um único documento de página da Web de várias linhas de execução.
- Consultas de contêiner: permitem que um único componente seja disposto de forma responsiva, desbloqueando todo um universo de componentes plug-and-play (atualmente uma implementação experimental).
- Isolamento de origem: permite que os sites ativem mais isolamento de desempenho entre iframes.
- Paint worklets fora da linha de execução principal: oferece aos desenvolvedores uma maneira de estender a forma como os elementos são pintados, com um código executado na linha de execução do compositor.
Além das APIs da Web explícitas, o RenderingNG nos permitiu enviar vários "recursos automáticos" muito importantes que beneficiam todos os sites:
- Isolamento de site: coloca iframes de origem cruzada em diferentes processos de CPU, para melhor segurança e isolamento de desempenho.
- Vulkan, D3D12 e Metal: aproveita APIs de nível mais baixo que usam GPUs com mais eficiência do que o OpenGL.
- Mais animações compostas: SVG, cor de plano de fundo.
Outros recursos que serão desbloqueados pelo RenderingNG e que nos deixam animados incluem:
- Animações vinculadas à rolagem.
- DOM oculto, mas pesquisável e acessível.
- Transições de elementos compartilhados.
- Layout personalizado.
- Composição fora da linha de execução principal; desacoplagem de linhas de execução e composição.
Principais projetos que compõem o RenderingNG
Confira uma lista dos principais projetos do RenderingNG.
CompositeAfterPaint
A CompositeAfterPaint separa a composição do estilo, layout e pintura, permitindo uma confiabilidade muito melhor e um desempenho previsível, maior taxa de transferência e o uso de menos memória sem sacrificar o desempenho.
| Ano | Progresso |
|---|---|
| 2015 | Enviar listas de exibição. |
| 2017 | Enviar nova invalidação. |
| 2018 | Árvores de propriedades do navio, parte 1. |
| 2019 | Árvores de propriedades do Ship, parte 2. |
| 2021 | Concluiu o envio do projeto. |
LayoutNG
Uma reescrita completa de todos os algoritmos de layout, para melhorar a confiabilidade e ter um desempenho mais previsível.
Leia mais sobre o LayoutNG.
| Ano | Progresso |
|---|---|
| 2019 | Fluxo de bloco de navios. |
| 2020 | Ship flex, editing. |
| 2021 | Envie todo o resto. |
BlinkNG
Reformulamos e limpamos o motor de renderização do Blink em fases de pipeline separadas. Isso permite um melhor armazenamento em cache, maior confiabilidade e recursos de renderização reentrante ou atrasada, como consultas de visibilidade de conteúdo e consultas de contêiner.
Aceleração de GPU em todos os lugares
A aceleração da GPU oferece uma enorme aceleração para a maioria do conteúdo, porque cada pixel pode ser processado em paralelo. Ele também é um método eficaz para melhorar o desempenho em dispositivos mais simples, que tendem a ter uma GPU.
| Ano | Progresso |
|---|---|
| 2014 | Suporte a tela Enviado no conteúdo de ativação no Android. |
| 2016 | Envie no Mac. |
| 2017 | A GPU é usada em mais de 60% das visualizações de página do Android. |
| 2018 | Enviar no Windows, ChromeOS e Android Go. |
| 2019 | Rastreamento de GPU com linha de execução. |
| 2020 | Envie o conteúdo restante do Android. |
Rolagem, animações e decodificação em linha de execução
Um esforço de longo prazo para mover todas as animações de rolagem, não indutoras de layout e de decodificação de imagens da linha de execução principal. Ele está em andamento.
| Ano | Progresso |
|---|---|
| 2011 | Suporte inicial para rolagem e animação em linha de execução. |
| 2015 | Redução de camadas. |
| 2016 | Rolagem de estouro universal. |
| 2017 | A imagem é decodificada na linha de execução do compositor. |
| 2018 | Animações de imagem na linha de execução do compositor. |
| 2020 | Sempre composições de posição fixa. |
| 2021 | Animações de transformação de porcentagem, animações SVG. |
Viz
Um processo de rasterização e renderização centralizado para o Chromium que aumenta a capacidade de processamento, otimiza a memória e permite o uso ideal dos recursos de hardware. Ele tem outros benefícios menos visíveis para desenvolvedores da Web, mas muito visíveis para os usuários, como desbloquear o isolamento do site e desacoplar o pipeline de renderização da renderização da interface do navegador.
| Ano | Progresso |
|---|---|
| 2018 | O OOP-R foi enviado para Android, Mac e Windows. |
| 2019 | O OOP-D foi enviado. O OOP-R foi enviado para todos os lugares (exceto o Canvas). O SkiaRenderer foi enviado no Linux. |
| 2020 | O SkiaRenderer foi enviado para Windows e Android. O Vulkan foi enviado no Android. |
| 2021 | O SkiaRenderer foi enviado para Mac (e em breve para ChromeOS). |
Definições dos termos no gráfico acima:
- OOP-D
- Compositor de exibição fora do processo. A composição de exibição é o mesmo tipo de atividade de um compositor do SO. Fora do processo significa fazer isso no processo de visualização em vez do processo de renderização da página da Web ou da interface do navegador.
- OOP-R
- Raster fora do processo. A rasterização está convertendo listas de exibição em pixels. Fora do processo significa fazer isso no processo de visualização em vez do processo de renderização da página da Web.
- SkiaRenderer
- Uma nova implementação de compositor de exibição que pode oferecer suporte à execução em várias APIs de GPU diferentes, como Vulkan, D3D12 ou Metal.
Renderização de tela com linha de execução e acelerada
Este é o projeto que tornou o OffscreenCanvas possível.
| Ano | Progresso |
|---|---|
| 2018 | Enviar OffscreenCanvas. |
| 2019 | Enviar ImageBitmapRenderingContext. |
| 2021 | Enviar OOP-R. |
VideoNG
O VideoNG é um esforço de longo prazo para oferecer reprodução de vídeo eficiente, confiável e de alta qualidade na Web.
| Ano | Progresso |
|---|---|
| 2014 | Introdução de um framework de renderização baseado em Mojo. |
| 2015 | O Project Butter e as sobreposições de vídeo foram enviados para renderização de vídeo mais suave. |
| 2016 | Foram enviados pipelines unificados de renderização e decodificação para Android e computadores. |
| 2017 | Renderização de vídeo com HDR e correção de cor. |
| 2018 | Pipeline de decodificação de vídeo baseado em Mojo enviado. |
| 2019 | Pipeline de renderização de vídeo baseado em Surface enviado. |
| 2021 | Suporte para renderização de conteúdo protegido em 4K no ChromeOS. |
Definições dos termos no gráfico acima:
- Mojo
- Um subsistema IPC de última geração para Chromium.
- Superfície
- Um conceito que faz parte do design do projeto de visualização.
Ilustrações de Una Kravets.