WebRender de Mozilla elevó páginas con tartamudeo de 15 FPS a 60 FPS con renderizado de motor de juego

Los navegadores habían pasado años volviéndose más fluidos haciendo menos: invalidando solo los rectángulos modificados, almacenando piezas en caché como capas, componiéndolas y, finalmente, trasladando ambas tareas a la GPU. En Mozilla Hacks en octubre de 2017, Lin Clark explicó por qué las páginas seguían tartamudeando. Las capas cuestan memoria y tiempo de transferencia, y los navegadores tienen que adivinar cuántas necesita una página. Demasiadas capas llenan la memoria y retrasan el compositor; demasiado pocas hacen que una capa repintada se componga sin que nada haya cambiado, tocando cada píxel dos veces. Animar un color de fondo obliga a repintar toda la capa sin importar qué.

WebRender, tecnología de Servo que llegaba a Firefox como Quantum Render, siguió un precedente diferente: los motores de juegos 3D repintan cada píxel de cada fotograma y mantienen 60 FPS de forma más fiable que los navegadores, en GPUs con cientos o miles de núcleos que sombrean píxeles en paralelo. Así que WebRender eliminó la frontera entre pintado y composición. La salida del layout se convirtió en una lista de visualización de instrucciones de dibujo de alto nivel no ligadas a ninguna API gráfica. El RenderBackend de WebRender convertía esa lista en llamadas de dibujo de GPU agrupadas, y la GPU repintaba toda la escena visible de la página en cada fotograma, sin adivinar capas.

Hacer asequible el redibujado de fotograma completo requirió eliminar trabajo. Los elementos fuera de pantalla se descartaban antes de llegar a la GPU. Un árbol de tareas de renderizado planificaba el número mínimo de costosas texturas fuera de pantalla para filtros y contextos de apilamiento. Las llamadas de dibujo se agrupaban para mantener ocupados los núcleos paralelos de la GPU. El renderizado se dividió en una pasada opaca de delante hacia atrás que omitía los píxeles cubiertos y una pasada translúcida de atrás hacia delante —z-culling, según el artículo, y una gran ventaja en páginas típicas—. Los glifos de texto siguieron siendo una tarea de CPU, pero se almacenaron en caché en una textura conservada de un fotograma a otro.

El objetivo era la consistencia, no solo la velocidad: sin precipicios de rendimiento, 60 FPS fluidos por grande que fuera la pantalla o por mucho que cambiara la página. El artículo informaba de que las páginas que avanzaban a trompicones a 15 FPS en Chrome o en el Firefox de la época se ejecutaban a 60 FPS con WebRender, y enmarcaba el trabajo como preparación para pantallas 4K y para WebVR, que renderiza un fotograma para cada ojo a 90 FPS.

Dejar de adivinar capas: entregar a la GPU una lista de visualización de alto nivel y repintar toda la página en cada fotograma, al estilo de un motor de juego

Las GPUs tienen de cientos a miles de núcleos que sombrean píxeles en paralelo, así que repintar toda la página visible en cada fotograma es la carga de trabajo para la que fueron construidas, no una tarea del tamaño de una CPU.

Una lista de visualización retenida es una descripción pequeña e independiente de la API de la escena, así que la CPU construye los comandos una vez y el RenderBackend puede descartarlos, ordenarlos y agruparlos antes de que ocurra cualquier trabajo de píxeles.

El redibujado de toda la escena elimina la conjetura de capas y sus modos de fallo: sin recuentos de capas mal calculados, sin doble manejo de píxeles, así que los tiempos de fotograma dejan de caer por precipicios de rendimiento.

La eliminación de trabajo mantiene barato el redibujado: el descarte, menos objetivos fuera de pantalla, la agrupación y el z-culling reducen lo que sombrea la GPU, mientras que los glifos renderizados por la CPU viven en una caché de texturas, no en la ruta de cada fotograma.

Cuando las heurísticas incrementales siguen chocando con precipicios del peor caso, cambia el modelo: describe toda la escena una vez y deja que el hardware masivamente paralelo la redibuje en cada fotograma

WebRender no estaba en la versión de Firefox Quantum que siguió: Lin Clark escribió en los comentarios del artículo que no llegaría hasta después de Firefox 57, y la pieza planificaba la integración hasta 2018 bajo el proyecto Quantum Render, con una versión temprana ya disponible tras un flag. La demostración que enlazaba mostraba páginas que se ejecutaban a 15 FPS en Chrome o en el Firefox de la época corriendo a 60 FPS con WebRender, y el explicativo reunió 853 puntos y 207 comentarios en Hacker News el 10 de octubre de 2017.