Listo para la nueva generación de contenido web
RenderingNG es una arquitectura de renderización de nueva generación que tiene un rendimiento superior al anterior. RenderingNG se compiló a lo largo de más de ocho años y representa el trabajo colectivo de muchos desarrolladores dedicados de Chromium. Permite desbloquear un gran potencial para el contenido web rápido, fluido, confiable, interactivo y responsivo.
Aquí, verás lo que creamos, por qué lo hicimos y cómo funciona.
Objetivo North Star
El objetivo norteamericano que motiva a RenderingNG es que la implementación del motor del navegador y la riqueza de sus APIs de renderización no deben ser un factor limitante de la UX en la Web.
No tienes que preocuparte por que los errores del navegador hagan que las funciones no sean confiables o afecten la renderización de tu sitio.
No debería haber acantilados misteriosos. Además, no deberías tener que ocuparte de las funciones integradas que faltan.
Simplemente debería funcionar.
RenderizarNG es un gran paso hacia esta meta. Antes de RenderingNG, podíamos agregar (y lo hicimos) funciones de renderización y mejorar el rendimiento, pero nos costó lograr que esas funciones fueran confiables para los desarrolladores, y había muchos obstáculos en el rendimiento. Ahora tenemos una arquitectura que resuelve de forma sistemática muchos de esos problemas y desbloquea funciones avanzadas que antes no se consideraban posibles. Por ejemplo:
- Tiene funciones principales sólidas en diferentes combinaciones de plataforma, dispositivo y sistema operativo.
- Tiene un rendimiento predecible y confiable.
- Maximiza el uso de capacidades de hardware (núcleos, GPU, resolución de pantalla, frecuencias de actualización, APIs de trama de bajo nivel).
- Solo realiza el trabajo necesario para mostrar contenido visible.
- Incluye compatibilidad integrada con patrones comunes de diseño visual, animación e interacción.
- Proporciona APIs para desarrolladores para administrar fácilmente los costos de renderización.
- Proporciona puntos de extensión de canalización de renderización para complementos para desarrolladores.
- Optimiza todo el contenido: HTML, CSS, lienzo 2D, lienzo 3D, imágenes, videos y fuentes.
Comparación con otros motores de renderización del navegador
Gecko y Webkit también implementaron la mayoría de las características arquitectónicas descritas en estas entradas de blog y, en algunos casos, incluso las agregaron antes de Chromium.
Cualquier navegador que se vuelva más rápido y confiable es motivo de celebración y tiene un impacto real. El objetivo final es avanzar en el modelo de referencia para todos los navegadores, de modo que los desarrolladores puedan confiar en él.
La pirámide del éxito
Mi filosofía es que el éxito es el resultado de primero lograr la confiabilidad, luego, el rendimiento escalable y, por último, la extensibilidad.
Al igual que en una pirámide de la vida real, cada nivel proporciona una base necesaria para el nivel superior.
Confiabilidad
Si las experiencias del usuario enriquecidas y complejas fueran posibles, lo primero que necesitamos es una plataforma sólida. Las funciones principales y los fundamentos deben funcionar correctamente y seguir funcionando con el tiempo. Y es igual de importante que esos atributos se compongan bien y no tengan comportamientos extraños en los casos extremos ni errores.
Por este motivo, la confiabilidad es la parte más importante de RenderingNG. La confiabilidad es el resultado de buenas pruebas, ciclos de reacción de calidad, métricas y patrones de diseño de software.
Para dar una idea de lo importante que es la confiabilidad, pasamos la mayoría de los últimos ocho años. En primer lugar, desarrollamos un conocimiento profundo del sistema: aprendimos de los informes de errores donde se encontraban los puntos débiles y los solucionamos, iniciando pruebas integrales y comprendiendo las necesidades de rendimiento de los sitios y las limitaciones del rendimiento de Chromium. Luego, diseñamos e implementamos de manera gradual y cuidadosa e implementamos patrones de diseño clave y estructuras de datos. Solo entonces estábamos listos para agregar primitivas de nueva generación para el diseño responsivo, la escalabilidad y la personalización de la renderización.
Sin embargo, esto no quiere decir que no se haya mejorado nada en Chromium durante ese período. De hecho, ocurre lo contrario. Esos años vieron un aumento constante y sostenido en la confiabilidad y el rendimiento a medida que refactorizamos e implementamos cada mejora paso a paso.
Pruebas y métricas
En los últimos 8 años, agregamos decenas de miles de pruebas de integración, rendimiento y unidad. Además, desarrollamos métricas integrales que miden muchos aspectos del comportamiento de la renderización de Chromium en pruebas locales, comparativas de rendimiento y en entornos reales en sitios reales, con usuarios y dispositivos reales.
Sin embargo, independientemente de lo bueno que sea RenderingNG (o, en realidad, el motor de renderización de otro navegador), no será fácil desarrollar contenido para la Web si existen muchos errores o diferencias de comportamiento entre los navegadores. Para solucionar este problema, también maximizamos el uso de las pruebas de la plataforma web. Cada una de estas pruebas verifica un patrón de uso de la plataforma web que todos los navegadores deben aprobar. También supervisamos de cerca las métricas para aprobar más pruebas con el tiempo y aumentar la compatibilidad principal.
Las pruebas de la plataforma web son un esfuerzo colaborativo. Por ejemplo, los ingenieros de Chromium agregaron solo alrededor del 10% del total de pruebas WPT para las funciones de CSS; otros proveedores de navegadores, colaboradores independientes y autores de las especificaciones contribuyen al resto. Se necesita toda una comunidad para construir la red interoperable.
Buenos patrones de diseño de software
La entrega confiable de software de calidad es, a su vez, mucho más fácil si el código es fácil de entender y está diseñado de manera que minimice la probabilidad de errores. Tendremos más que hablar sobre el diseño del software de RenderingNG en las próximas entradas del blog.
Rendimiento escalable
Lograr un gran rendimiento, en las dimensiones de velocidad, memoria y uso de energía, es el siguiente aspecto más importante de RenderingNG. Queremos que las interacciones con todos los sitios web sean fluidas y responsivas, pero que no sacrifiquen la estabilidad del dispositivo.
Pero no solo queremos rendimiento, sino también escalable, una arquitectura que funcione bien de manera confiable en máquinas de gama baja y alta, y en todas las plataformas de SO. A esto lo llamo aumentar la escala, aprovechar todo lo que el dispositivo de hardware puede lograr y reducir la escala verticalmente, lo que maximiza la eficiencia y reduce la demanda en el sistema cuando sea necesario.
Para lograrlo, tuvimos que aprovechar al máximo el almacenamiento en caché, el aislamiento del rendimiento y la aceleración de hardware de la GPU. Analicemos cada uno a la vez. Para ser concreto, pensemos en cómo cada una de ellas contribuye al rendimiento de una interacción extremadamente importante en las páginas web: el desplazamiento.
Almacenar en caché
En una plataforma de IU interactiva y dinámica, como la Web, el almacenamiento en caché es la forma más importante de mejorar drásticamente el rendimiento. El tipo más conocido de almacenamiento en caché en un navegador es la caché HTTP, pero el procesamiento también tiene muchas cachés. La caché más importante para el desplazamiento son las texturas de la GPU y las listas de visualización almacenadas en caché, que permiten que el desplazamiento sea extremadamente rápido y, al mismo tiempo, minimiza el agotamiento de la batería y funciona bien en una variedad de dispositivos.
El almacenamiento en caché mejora la duración de batería y la velocidad de fotogramas de la animación para el desplazamiento, pero lo más importante es que desbloquea el aislamiento de rendimiento del subproceso principal.
Aislamiento de rendimiento
En las computadoras de escritorio modernas, nunca tendrás que preocuparte de que las aplicaciones en segundo plano retrasen la de tu trabajo. Esto se debe a la multitarea preventiva, que, a su vez, es una forma de aislamiento del rendimiento: asegurarse de que las tareas independientes no se ralenticen entre sí.
En la Web, el mejor ejemplo de aislamiento de rendimiento es el desplazamiento. Incluso en sitios web con mucho JavaScript lento, el desplazamiento puede ser muy fluido, ya que se ejecuta en un subproceso diferente que no depende de JavaScript ni del subproceso de diseño. Nos esforzamos mucho en RenderingNG para asegurarnos de que todos los desplazamientos posibles se agrupen en subprocesos, a través del almacenamiento en caché que va mucho más allá de una lista de visualización a situaciones más complejas. Algunos ejemplos incluyen código para representar elementos de posición fija y fija, objetos de escucha de eventos pasivos y renderización de texto de alta calidad.
Aceleración de GPU
Una GPU agiliza mucho la generación de píxeles y el dibujo en la pantalla. En muchos casos, cada píxel se puede dibujar en paralelo con cada uno de los píxeles, lo que genera un gran aumento de velocidad. Un componente clave de RenderingNG es la trama de GPU y dibuja en todas partes. Esto usa la GPU en todas las plataformas y dispositivos para acelerar la renderización y la animación del contenido web. Esto es muy importante en dispositivos de gama baja o de gama alta, que suelen tener una GPU mucho más capaz que otras partes del dispositivo.
Extensibilidad: Las herramientas adecuadas para el trabajo
Una vez que tengamos la confiabilidad y el rendimiento escalable, podremos compilar con una serie de herramientas que ayuden a los desarrolladores a extender las partes integradas de HTML, CSS y Canvas, y de maneras en las que no se sacrifique el rendimiento ni la confiabilidad.
Esto incluye las APIs integradas y expuestas de JavaScript para casos de uso avanzados de diseño responsivo, renderización progresiva, fluidez y capacidad de respuesta, y renderización en subprocesos.
Las siguientes APIs de Web abierta, impulsadas por Chromium, se pudieron implementar mediante RenderingNG, y anteriormente se consideraron inviables.
Todos se desarrollaron con especificaciones abiertas y colaboración con socios web abiertos: ingenieros de otros navegadores, expertos y desarrolladores web. En entradas de blog posteriores, profundizaremos en cada una de ellas y explicaremos cómo RenderingNG los hace posibles.
- content-visibility: Permite que los sitios eviten fácilmente el trabajo de renderización del contenido fuera de pantalla y el procesamiento de la caché para las vistas de aplicaciones de una sola página que no se muestran actualmente.
- OffscreenCanvas: Permite que el renderizado de lienzo (tanto la API de 2D Canvas como WebGL) se ejecute en su propio subproceso y, así, obtener un rendimiento excelente de manera confiable. Este proyecto también es otro hito importante para la Web: es la primera API web que permite que JavaScript (o WebAssembly) renderice un único documento de página web a partir de varios subprocesos.
- Consultas de contenedores: Permiten que un solo componente se distribuya de manera responsiva, lo que desbloquea un universo entero de componentes listos para usar (actualmente, una implementación experimental).
- Aislamiento de origen: Permite que los sitios tengan un aislamiento mayor de rendimiento entre iframes.
- worklets de pintura fuera del subproceso principal: Proporciona a los desarrolladores una forma de extender la forma en que se pintan los elementos, con código que se ejecuta en el subproceso del compositor.
Además de las APIs web explícitas, RenderingNG nos permitió publicar varias "funciones automáticas" muy significativas que benefician a todos los sitios:
- Aislamiento de sitios: Coloca iframes de origen cruzado en diferentes procesos de CPU para mejorar el aislamiento de seguridad y rendimiento.
- Vulkan, D3D12 y Metal: Aprovecha las APIs de nivel inferior que usan las GPU de manera más eficiente que OpenGL.
- Más animaciones compuestas: SVG, color de fondo.
Entre las próximas funciones adicionales que RenderingNG desbloqueará, que nos entusiasman se incluyen las siguientes:
- Animaciones vinculadas con el desplazamiento.
- DOM oculto, pero que se puede buscar y acceder a él.
- Transiciones de elementos compartidos.
- Diseño personalizado.
- Composición fuera del subproceso principal; separación de subprocesos y composición.
Proyectos clave que componen RenderingNG
A continuación, se incluye una lista de proyectos clave dentro de RenderingNG.
CompositeAfterPaint
CompositeAfterPaint desenreda la composición del estilo, el diseño y la pintura, lo que permite una confiabilidad mejorada y un rendimiento predecible, una mayor capacidad de procesamiento y un uso menor de memoria sin sacrificar el rendimiento.
| Año | Progreso |
|---|---|
| 2015 | Envía listas de visualización. |
| 2017 | Envía una invalidación nueva. |
| 2018 | Árboles de propiedad de envío parte 1. |
| 2019 | Árboles de propiedad de envío parte 2. |
| 2021 | Se completó el envío del proyecto. |
LayoutNG
Una reescritura inicial de todos los algoritmos de diseño para mejorar la confiabilidad y el rendimiento más predecibles
Obtén más información sobre LayoutNG.
| Año | Progreso |
|---|---|
| 2019 | Flujo de bloque de envío. |
| 2020 | Envío flexible y editando |
| 2021 | Envía todo lo demás. |
BlinkNG
Refactorizamos y limpiamos el motor de renderización de Blink en fases de canalización separadas de forma clara. Esto permite un mejor almacenamiento en caché, mayor confiabilidad y funciones de renderización reentrante o retrasada, como la visibilidad del contenido y las consultas de contenedor.
Aceleración de GPU en todas partes
La aceleración de GPU proporciona una aceleración enorme para la mayoría del contenido, ya que cada píxel se puede procesar en paralelo. También es un método eficaz para mejorar el rendimiento en dispositivos de gama baja, que todavía tienen una GPU.
| Año | Progreso |
|---|---|
| 2014 | Compatibilidad con Canvas Se envían en contenido que se debe habilitar en Android. |
| 2016 | Enviar en Mac. |
| 2017 | La GPU se usa en más del 60% de las vistas de páginas de Android. |
| 2018 | Envíala en Windows, ChromeOS y Android Go. |
| 2019 | Rasterización por subprocesos de GPU. |
| 2020 | Envía el contenido restante de Android. |
Desplazamiento de subprocesos, animaciones y decodificación
Es un esfuerzo a largo plazo para quitar del subproceso principal todas las animaciones de desplazamiento, las animaciones que no induzcan el diseño y la decodificación de imágenes. Está en curso.
| Año | Progreso |
|---|---|
| 2011 | Compatibilidad inicial con el desplazamiento en subprocesos y la animación. |
| 2015 | Compresión de capas. |
| 2016 | Desplazamiento universal de desbordamiento. |
| 2017 | La imagen se decodifica en el subproceso del compositor. |
| 2018 | Animaciones de imágenes en un subproceso del compositor. |
| 2020 | Siempre compuesto en posición fija. |
| 2021 | Animaciones de transformación de porcentaje, animaciones SVG. |
visualización
Un proceso de generación y trama centralizado para Chromium que aumenta la capacidad de procesamiento, optimiza la memoria y permite el uso óptimo de las capacidades del hardware. Ofrece otros beneficios menos visibles para los desarrolladores web, pero muy visibles para los usuarios, como el desbloqueo del aislamiento de sitios y la separación de la canalización de procesamiento de la renderización de la IU del navegador.
| Año | Progreso |
|---|---|
| 2018 | OOP-R se envía en Android, Mac y Windows. |
| 2019 | OOP-D enviado. OOP-R se envía a todas partes (excepto Canvas). SkiaRenderer se envió en Linux. |
| 2020 | SkiaRenderer se envió en Windows y Android. Vulkan se envió en Android. |
| 2021 | SkiaRenderer se envió en Mac (y ChromeOS próximamente). |
Definiciones de términos en el gráfico anterior:
- OOP‐D
- El compositor de pantalla está fuera de proceso. La composición de pantalla es el mismo tipo de actividad que un compositor de SO. Sin proceso, significa hacerlo en el proceso de Viz en lugar del proceso de renderización de la página web o de la IU del navegador.
- OOP-R
- Trama fuera de proceso La trama convierte listas de visualización en píxeles. Fuera del proceso significa hacerlo en el proceso de Viz en lugar del proceso de renderización de la página web.
- SkiaRenderer
- Es una nueva implementación del compositor de pantalla que puede admitir la ejecución en una variedad de APIs subyacentes de GPU, como Vulkan, D3D12 o Metal.
Renderización de lienzo en subproceso y acelerado
Este es el proyecto que hizo posible OffscreenCanvas.
| Año | Progreso |
|---|---|
| 2018 | Envía OffscreenCanvas. |
| 2019 | Se envía ImageBitmapRenderingContext. |
| 2021 | Enviar OOP-R. |
VideoNG
VideoNG es una iniciativa a largo plazo para proporcionar una reproducción de video eficiente, confiable y de alta calidad en la Web.
| Año | Progreso |
|---|---|
| 2014 | Se introdujo un framework de renderización basado en Mojo. |
| 2015 | Se enviaron Project Butter y superposiciones de video para lograr una renderización de video más fluida. |
| 2016 | Se enviaron canalizaciones de renderización y decodificación unificadas para Android y computadoras de escritorio. |
| 2017 | Se envió la renderización del video con corrección de color y HDR. |
| 2018 | Se envió la canalización de decodificación de video basada en Mojo. |
| 2019 | Canalización de renderización de video basada en la superficie enviada |
| 2021 | Se envió compatibilidad con procesamiento de contenido protegido en 4K en ChromeOS. |
Definiciones de términos en el gráfico anterior:
- Mojo
- Un subsistema de IPC de nueva generación para Chromium.
- Superficie
- Es un concepto que forma parte del diseño del proyecto de Viz.
Ilustraciones de Una Kravets.