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.)
• 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).

// 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
• Siguiente: La paint thread