El pipeline de píxeles: estilo, layout, paint y composición

Cada vez que algo cambia en la página, el navegador ejecuta una secuencia fija de etapas para producir el fotograma siguiente. La secuencia es siempre la misma y siempre en el mismo orden; lo único que varía es cuántas etapas se pueden saltar. Ese modelo mental —qué etapas hay, cuál depende de cuál, y cuál corre en qué hilo— es la base de todo lo que se puede decir sobre rendimiento de renderizado, y es sorprendentemente poco conocido incluso entre gente que lleva años optimizando interfaces.

Las ocho etapas

flowchart TB
A[Entrada del usuario y devoluciones de fotograma] --> B[Recalculo de estilo]
B --> C[Layout o calculo de geometria]
C --> D[Pre paint y arboles de propiedades]
D --> E[Paint que graba la lista de dibujo]
E --> F[Commit al hilo compositor]
F --> G[Rasterizado en mosaicos]
G --> H[Dibujo de los quads en la GPU]
H --> I[Fotograma presentado en pantalla]
style A fill:#89b4fa,color:#11111b
style B fill:#89b4fa,color:#11111b
style C fill:#f9e2af,color:#11111b
style D fill:#cba6f7,color:#11111b
style E fill:#f9e2af,color:#11111b
style F fill:#89b4fa,color:#11111b
style G fill:#fab387,color:#11111b
style H fill:#fab387,color:#11111b
style I fill:#a6e3a1,color:#11111b

La frontera está entre la sexta y la séptima. De la primera a la sexta, todo ocurre en el hilo principal, el mismo que ejecuta tu JavaScript. De la séptima en adelante, el trabajo lo hacen el hilo compositor, los hilos de rasterizado y el proceso de la GPU. Esa separación es la decisión arquitectónica más importante del navegador moderno y es la razón de que ciertas animaciones sean inmunes a que tu código bloquee.

Etapa por etapa.

Entrada y devoluciones de fotograma. El fotograma empieza atendiendo los eventos de entrada pendientes y ejecutando las devoluciones registradas con requestAnimationFrame. Todo lo que hagas aquí es tiempo del presupuesto del fotograma.

Recálculo de estilo. Para cada elemento cuyo estilo se haya invalidado, resolver qué valor gana en cada propiedad: emparejar selectores, aplicar la cascada, heredar lo heredable, resolver unidades relativas. El resultado es un estilo calculado por elemento. El coste escala con cuántos elementos hay que reevaluar, no con cuántas propiedades tocaste: cambiar una clase que afecta a tres mil elementos cuesta tres mil recálculos aunque la clase solo defina un color.

Los motores no reevalúan el documento entero por cada cambio. Mantienen estructuras de invalidación que, dado un cambio concreto —esta clase, este atributo, esta propiedad personalizada— saben acotar el conjunto de elementos que pueden verse afectados. Esa maquinaria funciona muy bien y se degrada con selectores que dependen de relaciones amplias del árbol.

Layout. Calcular la geometría: el tamaño y la posición de cada caja. Es la etapa más cara y la que peor se acota, porque el resultado de una caja depende de sus hermanas, de sus ancestros y de sus descendientes a la vez. Cambiar la anchura de un elemento puede obligar a recalcular la mitad del documento.

Pre-paint. Una etapa que existe en los motores modernos y que la gente no suele conocer. Aquí se actualizan los árboles de propiedades —transformaciones, recortes, efectos, desplazamientos— que describen cómo se relacionan geométricamente las distintas partes del documento, y se decide qué hay que volver a pintar. Es la etapa que hace posible que muchas cosas se resuelvan después sin repintar nada.

Paint. Y aquí está el malentendido más extendido de todo el tema: pintar no produce píxeles. Paint genera una lista de dibujo: una secuencia de órdenes del tipo “rellena este rectángulo con este color”, “dibuja este texto con esta fuente en esta posición”, “aplica este degradado en esta caja”. Es una estructura de datos, no un mapa de bits. Por eso pintar es relativamente barato incluso en áreas grandes.

Commit. Se transfiere el árbol de capas con sus listas de dibujo al hilo compositor. A partir de aquí el hilo principal ha terminado su parte y puede ejecutar la tarea siguiente.

Rasterizado. Ahora sí aparecen los píxeles. Las listas de dibujo se ejecutan para producir mapas de bits, troceados en mosaicos, en hilos de rasterizado dedicados o aceleradas por la GPU. Es donde se paga de verdad el coste de una sombra grande, un desenfoque o un degradado complejo.

Dibujo. La GPU coloca las texturas resultantes en su sitio, con sus transformaciones y sus mezclas, y produce el fotograma que va al panel.

Saltarse etapas

La propiedad que hace útil todo este modelo: una etapa se puede omitir si ninguna de las anteriores produjo un cambio que la afecte. De ahí salen los tres caminos posibles.

El camino completo. Cambias algo geométrico, como la anchura de un elemento. Hay que recalcular estilo, rehacer el layout, actualizar las propiedades de pintura, volver a pintar, y todo lo demás. Es el caso caro.

El camino sin layout. Cambias algo que afecta al aspecto pero no a la geometría, como un color de fondo. Recálculo de estilo sí; layout no, porque ninguna caja ha cambiado de tamaño ni de posición; pintura sí, porque el contenido de la lista de dibujo cambia; y el resto también.

El camino solo de composición. Cambias algo que el compositor puede resolver él solo con la textura que ya tiene, como el desplazamiento de una capa o su opacidad. Recálculo de estilo mínimo, y después nada: no hay layout, no hay pintura, no hay rasterizado nuevo. El compositor coge la textura existente y la dibuja en otro sitio o con otra transparencia.

La diferencia de coste entre los tres caminos, para un cambio en un documento de tamaño medio:

Esos son los órdenes de magnitud que hay detrás de toda la sabiduría convencional sobre animar transform en vez de left. No es una superstición: es que uno de los dos recorre tres etapas del hilo principal y el otro ninguna.

// Pega esto en la consola con una animacion visible en pantalla
function bloquear(ms) {
  const fin = performance.now() + ms;
  while (performance.now() < fin) { /* ocupar el hilo principal */ }
}

setTimeout(() => bloquear(2000), 500);

elemento.addEventListener('scroll', alDesplazar, { passive: true });
elemento.addEventListener('touchmove', alTocar, { passive: true });

Lo que este modelo permite decidir

Con las ocho etapas en la cabeza, tres preguntas que antes eran vagas se vuelven concretas.

“¿Por qué esto va lento?” pasa a ser “¿en qué etapa se va el tiempo?”, que tiene respuesta medible.

“¿Cómo lo hago más rápido?” pasa a ser “¿puedo hacer que el cambio se salte alguna etapa?”, que tiene un repertorio finito de respuestas.

“¿Por qué a veces va bien y a veces mal?” pasa a ser “¿qué cambia el número de elementos que recorre cada etapa?”, que casi siempre apunta al tamaño del documento.

Las tres se desarrollan en las lecciones siguientes. Antes, hay que saber qué cambio dispara qué etapa, que es la pieza que falta.