Barrapunto

Lo mismo pasaba con los juegos. Conozco a alguien que propuso un parche para el framebuffer de linux que activaba polling activo para poder usar triple buffering en tarjetas Matrox MGA 200 y superiores al sincronizar exactamente los tiempos con los de la tarjeta.

Yo le hice de conejillo de indias y al igual que aquella vez con BeOS flipé: ya le podía meter caña de procesos y demás que la animación del juego era fluidísima por mucho ogg que tuviese reproduciéndose de fondo.

¿Problema? Permitía a un proceso de usuario hacer polling activo y ahogar la CPU, ni si quiera un proceso root podía evitarlo porque como el polling se hacía a nivel de núcleo, no se podía salir del mismo. Las Matrox tenía una interrupción que permitía evitar el polling, pero no había forma estándar de hacerlo en todas las tarjetas y debido a ello se descartó.

En resumen: todas estas cosas son y siguen siendo posibles, pero a costa de otras desventajas (dejar de tener un SO multiusuario/multiproceso y volver a tiempos del MSDOS).

Y sinceramente, desde que dejé los juegos prefiero un scheduler equitativo que un widget superfluído y el resto suplicando CPU. De hecho hoy me quejo por el jodido flash y sus trampas de CPU empotradas en HTML que me "cuelgan" el navegador, obligándome a usar filtros y addons que preferiría no tener que usar.

PD: Hace no mucho los chicos de Firefox se quejaban de que Safari bajo MacOSX usaba API no documentada para poder renderizar a 60fps mientras que la API normal recortaba la velocidad. Otro ejemplo de cómo saltarse las reglas mejora el rendimiento a costa de ciertas desventajas (presuntamente peor repartición de CPU, eso no he llegado a probarlo).