Pronto para a próxima geração de conteúdo da Web
O RenderingNG é uma arquitetura de renderização de última geração e superou 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. Ela libera um enorme potencial para conteúdo da Web rápido, fluido, confiável, responsivo e interativo.
Aqui, você aprenderá o que construímos, por que e como funciona.
Meta da estrela norte
O principal objetivo que motiva o RenderingNG é que a implementação do mecanismo do navegador e a riqueza das APIs de renderização não devem ser um fator limitante da UX na Web.
Você não precisa se preocupar com bugs do navegador que prejudicam a confiabilidade dos recursos ou que corrompem a renderização do site.
Não deve haver falésias de desempenho misteriosos. Você não precisa contornar a falta de recursos integrados.
Deve funcionar.
A RenderingNG é um grande passo em direção a esse objetivo principal. Antes do RenderingNG, era possível adicionar recursos de renderização e melhorar o desempenho, mas havia dificuldade para tornar esses recursos confiáveis para os desenvolvedores, e havia muitos problemas 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 básicos 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 de tela, taxas de atualização, APIs de varredura de baixo nível).
- Executa apenas o trabalho necessário para mostrar conteúdo visível.
- Tem suporte integrado para padrões comuns de design visual, animação e design de interação.
- Fornece APIs de desenvolvedor para gerenciar facilmente os custos de renderização.
- Fornece pontos de extensão de pipeline de renderização para suplementos do desenvolvedor.
- Otimiza todo o conteúdo: HTML, CSS, tela 2D, tela 3D, imagens, vídeo e fontes.
Comparação com outros mecanismos de renderização de navegador
A Gecko e o Webkit também implementaram a maioria dos mesmos recursos de arquitetura descritos nestas postagens do blog e, em alguns casos, 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 é melhorar o valor de referência de 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 necessariamente sólida para o nível acima.
Confiabilidade
Se for possível criar experiências do usuário ricas e complexas, primeiro precisamos de uma plataforma sólida. Os recursos principais e as bases precisam funcionar corretamente e continuar funcionando ao longo do tempo. É igualmente importante que esses recursos tenham uma boa composição e não apresentem comportamentos extremos ou bugs estranhos.
Por esse motivo, a confiabilidade é a parte mais importante do RenderingNG. E confiabilidade é o resultado de bons testes, ciclos de feedback de qualidade, métricas e padrões de design de software.
Para dar uma noção da importância da confiabilidade, passamos a maior parte dos últimos oito anos abordando apenas esta parte. Primeiro, construímos um conhecimento profundo do sistema, aprendendo com os relatórios de bugs onde estavam os pontos fracos e corrigindo-os, fazendo bootstrap de testes abrangentes e entendendo as necessidades de desempenho dos sites e as limitações de desempenho do Chromium. Em seguida, projetamos e implementamos com cuidado e de modo incremental os principais padrões de design e estruturas de dados. Só então estávamos prontos para adicionar primitivos de última geração para design responsivo, escalonabilidade e personalização de renderização.
Isso não quer dizer que nada foi melhorado durante esse período no Chromium. Na verdade, o oposto é verdadeiro. Esses anos tiveram um aumento constante e constante na confiabilidade e no desempenho, à medida que refatoramos e implementamos 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 de como a renderização do Chromium se comporta em testes locais, comparativos de desempenho de desempenho e em sites reais, com usuários e dispositivos reais.
Mas, independentemente da qualidade do RenderingNG (ou do mecanismo de renderização de outro navegador), ainda não será fácil desenvolver para a Web se houver muitos bugs ou diferenças de comportamento entre os navegadores. Para resolver isso, também maximizamos o uso dos testes da plataforma Web. Cada um desses testes verifica um padrão de uso da plataforma da Web que todos os navegadores devem tentar passar. Também monitoramos as métricas para passar em mais testes ao longo do tempo e aumentar a compatibilidade dos principais.
Os Testes de Plataformas da Web são um esforço colaborativo. Por exemplo, os engenheiros do Chromium adicionaram apenas cerca de 10% do total de testes de WPT para recursos de CSS. Outros fornecedores de navegadores, colaboradores independentes e autores de especificações contribuem com o restante. É preciso uma vila para criar uma Web interoperável!
Bons padrões de design de software
Oferecer software de qualidade de forma confiável é, por sua vez, muito mais fácil se o código for fácil de entender e projetado de uma maneira que minimize a probabilidade de bugs. Teremos muito mais a dizer sobre o design do software do RenderingNG em outras postagens do blog.
Desempenho escalonável
Alcançar um ótimo desempenho em todas as 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 desempenho, queremos um desempenho escalonável, uma arquitetura com desempenho confiável e bom em máquinas de última geração e de última geração e em plataformas de SO. Eu chamo isso de escalonamento vertical, ou seja, aproveitar tudo o que o dispositivo de hardware pode alcançar, e reduzir a escala vertical, maximizando a eficiência e reduzindo a demanda no sistema quando necessário.
Para isso, precisávamos aproveitar ao máximo o armazenamento em cache, o isolamento de desempenho e a aceleração de hardware da GPU. Vamos analisar cada uma delas. Para esclarecer, vamos pensar em como cada um deles contribui para o desempenho de uma interação extremamente importante em páginas da Web: a rolagem.
Armazenamento em cache
Em uma plataforma de IU dinâmica e interativa, como a Web, o armazenamento em cache é a maneira mais importante de melhorar significativamente 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 da GPU e as listas de exibição, 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 na duração da bateria e no frame rate 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
Nos computadores desktop modernos, você não precisa se preocupar com a lentidão dos aplicativos em segundo plano em que você está trabalhando. Isso ocorre por causa da multitarefa preventiva, que, por sua vez, é uma forma de isolamento do desempenho: garantir que tarefas independentes não atrasem umas às 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 depende do JavaScript e da linha de execução de layout. Dedicamos muito esforço ao RenderingNG para garantir que cada rolagem possível seja encadeada, por meio do armazenamento em cache que vai muito além de apenas uma lista de exibição para situações mais complexas. Os exemplos incluem código para representar elementos fixos e fixos, 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 o desenho na tela muito mais rápidos. Em muitos casos, cada pixel pode ser desenhado em paralelo com qualquer outro pixel, resultando em um enorme aumento de velocidade. Um componente essencial do RenderingNG é a varredura da GPU e o desenho 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 mais simples ou muito sofisticados, que geralmente têm uma GPU muito mais eficiente do que outras partes do dispositivo.
Extensibilidade: as ferramentas certas para o trabalho
Quando tivermos confiabilidade e desempenho escalonável, estamos prontos para desenvolver uma série de ferramentas para ajudar os desenvolvedores a estender as partes integradas do HTML, CSS e Canvas e de maneiras que não sacrifiquem o desempenho e a confiabilidade conquistados a tempo.
Isso inclui APIs integradas e expostas por JavaScript para casos de uso avançados de design responsivo, renderização progressiva, suavidade, capacidade de resposta e renderização em linhas de execução.
As seguintes APIs da Web abertas, defendidas pelo Chromium, foram possibilitadas pelo RenderingNG e antes eram consideradas inviáveis.
Todas elas foram desenvolvidas com especificações abertas e colaboração com parceiros da Web abertos: engenheiros de outros navegadores, especialistas e desenvolvedores Web. Nas próximas postagens do blog, vamos nos aprofundar em cada um deles e explicar como o RenderingNG os torna possíveis.
- visibilidade do conteúdo: 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 não exibidas no momento.
- OffscreenCanvas: permite que a renderização de telas (tanto a API 2D canvas quanto o WebGL) seja executada na própria linha de execução para um desempenho confiável e excelente. Esse projeto também é outro marco importante para a Web: é a primeira API Web que permite que o JavaScript (ou WebAssembly!) renderize um único documento de página da Web a partir de várias linhas de execução.
- Consultas de contêiner: permitem que um único componente se apresente de forma responsiva, desbloqueando um universo inteiro de componentes prontos para usar (atualmente uma implementação experimental).
- Isolamento de origem: permite que os sites ativem mais isolamento de desempenho entre iframes.
- Worklets de pintura fora da linha de execução principal: oferecem aos desenvolvedores uma maneira de estender como os elementos são pintados, com código que é executado na linha de execução do compositor.
Além das APIs da Web explícitas, o RenderingNG nos permitiu oferecer vários "recursos automáticos" muito importantes que beneficiam todos os sites:
- Isolamento de sites: coloca iframes de origem cruzada em diferentes processos da CPU para melhorar a segurança e o isolamento do desempenho.
- Vulkan, D3D12 e Metal: aproveitam APIs de nível inferior que usam GPUs de maneira mais eficiente do que o OpenGL.
- Animações mais compostas: SVG, cor do plano de fundo.
Outros recursos futuros desbloqueados pelo RenderingNG com os quais estamos empolgados incluem:
- Animações vinculadas à rolagem.
- DOM oculto, porém pesquisável e acessível.
- Transições de elementos compartilhados.
- Layout personalizado.
- Composição fora da linha de execução principal; desacoplamento da linha de execução e da composição.
Principais projetos que compõem o RenderingNG
Esta é uma lista dos principais projetos no RenderingNG.
CompositeAfterPaint
O CompositeAfterPaint separa a composição do estilo, do layout e da pintura, permitindo muito mais confiabilidade e desempenho previsível, maior capacidade e 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 naval parte 1. |
| 2019 | Árvores de propriedades naval, parte 2. |
| 2021 | O envio do projeto foi concluído. |
LayoutNG
Uma regravação completa de todos os algoritmos de layout para aumentar a confiabilidade e o desempenho previsível.
Leia mais sobre o LayoutNG.
| Ano | Progresso |
|---|---|
| 2019 | Fluxo de blocos de navio. |
| 2020 | Enviar com flexibilidade, editando. |
| 2021 | Enviar todo o resto. |
BlinkNG
Refatoramos e limpamos o mecanismo de renderização Blink em fases de pipeline separadas de forma limpa. Isso permite melhor armazenamento em cache, maior confiabilidade e recursos de reentrada ou renderização atrasada, como visibilidade de conteúdo e consultas de contêiner.
Aceleração de GPU em qualquer lugar
A aceleração de GPU oferece uma enorme velocidade para a maioria do conteúdo, porque todos os pixels podem ser processados em paralelo. Também é um método eficaz para melhorar o desempenho em dispositivos mais simples, que costumam ter uma GPU.
| Ano | Progresso |
|---|---|
| 2014 | Suporte ao Canvas. Enviado com base em conteúdo opcional no Android. |
| 2016 | Enviar no Mac. |
| 2017 | A GPU é usada em mais de 60% das visualizações de página do Android. |
| 2018 | Lançar no Windows, ChromeOS e Android Go. |
| 2019 | Varredura da GPU em sequência. |
| 2020 | Enviar o conteúdo Android restante. |
Rolagem encadeada, animações e decodificação
Um esforço de longo prazo para remover da linha de execução principal todas as animações de rolagem, que não induzem layout e a decodificação de imagem. É um processo contínuo.
| Ano | Progresso |
|---|---|
| 2011 | Suporte inicial para animação e rolagem em sequência. |
| 2015 | Compressão de camadas. |
| 2016 | Rolagem flutuante 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 componha posição fixa. |
| 2021 | Animações de transformação percentual, animações SVG. |
Visualizações
Um processo centralizado de varredura e exibição para o Chromium que aumenta a capacidade, otimiza a memória e permite o uso ideal dos recursos de hardware. Ela tem outros benefícios menos visíveis para os desenvolvedores da Web, mas muito visível para os usuários, como desbloquear o isolamento de sites e desacoplar o pipeline de renderização da renderização da interface do navegador.
| Ano | Progresso |
|---|---|
| 2018 | OOP-R fornecido no Android, Mac e Windows. |
| 2019 | OOP-D enviado. OOP-R pode ser enviado em qualquer lugar (exceto no Canvas). O SkiaRenderer é fornecido no Linux. |
| 2020 | O SkiaRenderer é fornecido no Windows e no Android. Vulkan fornecido no Android. |
| 2021 | O SkiaRenderer será lançado no Mac (e no ChromeOS em breve). |
Definições dos termos no gráfico acima:
- OOP-D
- Compositor de exibição fora do processo. A composição de exibição tem o mesmo tipo de atividade que um compositor do SO. Fora do processo significa fazer isso no processo Viz em vez de no processo de renderização da página da Web ou do processo de interface do navegador.
- OOP-R
- Varredura fora do processo. A varredura está convertendo listas de exibição em pixels. Fora do processo significa fazer isso no processo Viz em vez de no processo de renderização da página da Web.
- SkiaRenderer
- Uma nova implementação do compositor de tela que oferece suporte à execução em uma variedade de APIs de GPU subjacentes, como Vulkan, D3D12 ou Metal.
Renderização de canvas encadeada e acelerada
Esse é o projeto que possibilitou o OffscreenCanvas.
| Ano | Progresso |
|---|---|
| 2018 | Enviar tela para fora da tela. |
| 2019 | Envie o ImageBitmapRenderingContext. |
| 2021 | Enviar OOP-R. |
VideoNG
O VideoNG é um esforço de longo prazo para oferecer uma reprodução de vídeos eficiente, confiável e de alta qualidade na Web.
| Ano | Progresso |
|---|---|
| 2014 | Introdução de um framework de renderização baseada em Mojo. |
| 2015 | Project Butter e sobreposições de vídeo enviados para uma renderização de vídeo mais suave. |
| 2016 | Envio de pipelines unificados de decodificação e renderização de Android e computadores. |
| 2017 | Envio do HDR e renderização de vídeo com cores corrigidas. |
| 2018 | Pipeline de decodificação de vídeo baseado em Mojo enviado. |
| 2019 | Pipeline de renderização de vídeo baseado em superfície enviado. |
| 2021 | Envio do 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 o Chromium.
- Superfície
- Um conceito que faz parte do design do projeto Viz.
Ilustrações de Una Kravets.