El cromo brillante de Windows XP costaba una GPU con aceleración. Nosotros lo queríamos en un 386 con VESA y unos pocos MB de RAM, dibujado enteramente por software. La solución tiene tres decisiones contraintuitivas, y las tres nacieron de la misma pregunta: ¿qué puede pagar de verdad esta máquina?
Decisión 1: componer siempre en 32 bits
Todo se dibuja en UN back buffer XRGB de 32 bits en RAM del sistema. Suena carísimo para la época y es lo contrario: el código de dibujo es independiente del formato y no hay dithering en ningún sitio. Los degradados, biseles y sombras se calculan una vez, limpios. Solo el paso present() convierte al formato real del hardware.
Decisión 2: una paleta que no se busca
A 8bpp usamos una paleta 3-3-2: tres bits de rojo, tres de verde, dos de azul. Convertir un píxel de 32 bits es un shift y una máscara —cero búsquedas en tablas, cero «color más cercano». A 16bpp, RGB565 directo. Y solo se convierten los rectángulos sucios: un clic repinta una ventana, no una pantalla.
No hay alpha por píxel en todo el sistema. Los iconos usan color key magenta; las sombras son un read-modify-write barato en los bordes.
Decisión 3: prohibir el alpha
La transparencia por píxel es el lujo que un 386 no puede pagar. Así que no existe: los iconos y cursores usan un color key magenta de 1 bit, y las sombras de las ventanas son un oscurecimiento barato de las franjas de borde. El resultado engaña al ojo exactamente igual, y cabe en el presupuesto. 457 tests en host y una tubería de capturas golden vigilan que ningún commit lo rompa.
D. ABELLÁN · FOUNDER · PRINCETON, IL · 2026.04.22