Ventanas
Semestre 02, 2026
De renderizado estático a tiempo real
Pintar la pantalla → mostrarla → limpiarla y repintar con ligeras modificaciones. Al repetirlo rápido se crea la ilusión de movimiento.
Framebuffer y GPU
- El framebuffer es memoria con el color de cada píxel.
- Con GPU, vive en la memoria de video y lo gestiona la tarjeta.
- Sin GPU, vive en la RAM y lo gestiona la CPU (software rendering).
La GPU habla con el monitor
- La tarjeta de video tiene la interfaz directa con el monitor.
- Convierte los bytes del framebuffer en una señal eléctrica que el monitor muestra.
- VGA, DVI, HDMI, etc. son también protocolos entre la GPU y el monitor.
Tearing
- El monitor lee el framebuffer muchas veces por segundo para refrescar la imagen.
- Si dibujamos sobre ese mismo framebuffer mientras el monitor lo lee, muestra parte del frame anterior y parte del nuevo.
- A ese artefacto lo llamamos tearing (desgarro).
Una línea horizontal donde la imagen “se parte”: arriba el frame viejo, abajo el nuevo.
Doble buffer
Cuando el frame está listo se intercambian: el monitor nunca ve un frame a medio dibujar. El vsync sincroniza ese swap con el refresco del monitor (p. ej. 60 Hz) para eliminar el tearing.
El driver de video
Escribir en la memoria de video es trabajo del driver, específico de cada fabricante.
Window System
- Varios programas quieren escribir en la pantalla al mismo tiempo.
- La aplicación no maneja coordenadas absolutas: el Window System las traduce a posiciones dentro del framebuffer.
- Provee la interfaz gráfica básica: ventanas, cursores y eventos de teclado y ratón.
El problema que resuelve
Ejemplo con X11
El servidor X11 gestiona la pantalla y las aplicaciones son sus clientes.
- Solicita un área de 800x600 al servidor X11.
- Reserva un espacio dentro del framebuffer.
- Dibuja sus elementos solo en ese espacio: a eso lo llamamos una ventana.
X11 y Wayland
El servidor X hace casi todo y el compositor se añadió después, encima. Cualquier cliente puede leer los eventos y el contenido de otras ventanas: hoy se considera un problema de seguridad.
El compositor y el servidor de display son lo mismo. Cada app dibuja su propia ventana en un buffer (lado del cliente) y se lo entrega al compositor, que solo los combina. Más simple, más seguro y con menos latencia.
El camino de un evento
Presionar una tecla o mover el ratón recorre varias capas antes de llegar al programa:
- El dispositivo genera una señal que el kernel recibe por su driver.
- X11 o Wayland recibe el evento desde el kernel.
- El servidor decide a qué ventana pertenece y le entrega el evento.
- La app lo lee en su fase de process_input().
Window Manager y Compositor
Para efectos complejos (transparencias, sombras, animaciones) combina las ventanas en la imagen final. Ejemplos: i3, KWin, Mutter, Quartz, DWM.
Organización por capas
┌─────────────────────────────────────┐
│ Window System │ ← X11, Wayland
│ ┌───────────────────────────────┐ │
│ │ Window Manager │ │ ← i3, KWin, Mutter
│ └───────────────────────────────┘ │
│ ┌───────────────────────────────┐ │
│ │ Applications │ │ ← Firefox, terminal…
│ └───────────────────────────────┘ │
└─────────────────────────────────────┘
↓
Framebuffer → GPU → Monitor
Window Toolkits
- Bibliotecas que facilitan crear interfaces gráficas abstrayendo el Window System y el Window Manager.
- Permiten crear ventanas, botones y menús sin manejar el framebuffer ni los eventos del sistema.
- Gestionan la comunicación con X11, Wayland, Quartz o DWM, y hacen el código portable.
En el proyecto de gráficas
- El proyecto no habla con X11 ni Wayland directamente.
- Se usa un toolkit (minifb, raylib, SDL) que da una ventana y un framebuffer donde escribir píxeles.
- El raytracer calcula un color por píxel y lo escribe en ese buffer; el toolkit hace el swap dentro del render loop.
Todas las capas que vimos (driver, Window System, Window Manager, compositor) siguen ahí debajo, pero el toolkit las abstrae por ti.