# El pipeline de renderizado > Cómo un pixel llega a la pantalla — Paint → renderizadores por primitiva → OpenGL — y qué es el batching. Source: https://crossfly.dev/es/docs/concepts/rendering-pipeline — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # El pipeline de renderizado Entender cómo el dibujo se convierte en pixels explica varias reglas de rendimiento del framework.

## Las capas del dibujo - **`Paint`** es la fachada con la que dibujas en `onPaint(...)`. Piensa en **coordenadas locales**, **clip** y **traslación** — y **no sabe nada de shaders** ni de OpenGL. Tú dices "dibuja este rectángulo aquí"; cómo eso se convierte en triángulos y llamadas de GPU no es problema tuyo. - **`gl` / renderizadores** — hay **un renderizador especializado por primitiva** (rectángulo, rectángulo redondeado, línea, texto, imagen…), cada uno esencialmente un shader. El `Paint` delega al renderizador correcto. - **OpenGL** — las *draw calls* finales. ## El concepto central: batching Los renderizadores agrupan dibujos del **mismo tipo** en lote (batch) para reducir llamadas de GPU. La regla que se deriva de esto: > **Cambiar de tipo de primitiva "cierra" el batch anterior.** El orden de dibujo siempre se preserva, pero > alternar tipos (rectángulo → texto → rectángulo → texto) fuerza varios flushes; **agrupar llamadas del > mismo tipo** es lo que da rendimiento. En la práctica, en dibujo custom pesado, dibujar todos los rectángulos juntos y luego todos los textos rinde más que intercalar. ## Render bajo demanda + repintado de árbol entero Dos propiedades del modelo de render que afectan cómo escribes `onPaint`: - **Bajo demanda:** la pantalla **solo se redibuja cuando alguien lo pide** (`repaint()` → `requestRendering()`). Sin solicitud, no se genera ningún frame nuevo — ahorra batería. (El ángulo de threading de esto está en [La paint thread](/docs/concepts/the-paint-thread).) - **Sin *dirty rectangles*:** cuando ocurre un frame, **se repinta todo el árbol visible**, no solo la parte que cambió. No hay repintado parcial. La consecuencia práctica es un principio: > **Mantén `onPaint` barato.** Se ejecuta para el árbol entero en cada frame renderizado — nada de > asignar objetos, cargar recursos o hacer cálculos caros dentro de él. ## Cómo se monta el frame (visión de alto nivel) En cada frame renderizado, el `EventsProcessor` pinta la **pila de ventanas** (vía `paintWindows(...)`): la ventana del tope por encima, las de abajo detrás (los popups dejan visible la anterior). Cada componente visible recibe su `onPaint(Paint)`. ```java // onPaint mínimo y barato: reutiliza temporales, dibuja en coords locales (0,0 = arriba-izquierda) @Override public void onPaint(Paint paint) throws Exception { paint.rect(scratch.bounds(0, 0, width, height).fill(bg)); // 'scratch' es un GRect reutilizado } ``` ## Ver también - Aplicar: [Dibujo personalizado](/docs/ui/images-and-graphics/custom-drawing) - Siguiente: [La paint thread](/docs/concepts/the-paint-thread)