Si está enfatizando sobre X como una fuente de sobrecarga en un sistema Linux moderno, probablemente no está buscando en el lugar correcto. X fue diseñado hace mucho tiempo para computadoras mucho menos poderosas que un teléfono celular moderno.
Si miras "arriba" y ves X usando la memoria, hay mucho trabajo por hacer para calcular la sobrecarga real de X. Hay mapas de memoria que no son "reales", y hay recursos (como grandes bloques de píxeles) asignados en nombre de las aplicaciones. En pocas palabras, la memoria que se muestra para X en la parte superior no es lo que uno podría pensar.
La gente también oye que X usa la "red" y piensa que esto será un cuello de botella de rendimiento. "Red" aquí significa socket local de dominio UNIX, que tiene una sobrecarga insignificante en Linux moderno. Cosas que bloquearían la red, hay extensiones X para hacer rápidas (mapas de memoria compartidos, DRI, etc.). Los hilos en proceso no necesariamente serían más rápidos que el socket X, porque los cuellos de botella tienen más que ver con el problema inherente de coordinar múltiples hilos o procesos que acceden al mismo hardware, que con la sobrecarga mínima de los sockets locales.
La configuración multiproceso tiene muchas ventajas, como ser mucho más difícil de bloquear.Vea Google Chrome, por ejemplo, usando múltiples procesos para ser más robusto, y resulta que también se ejecuta rápido. Menos procesos no significa necesariamente más moderno.
Hay muchas razones por las que las aplicaciones que usan GTK no transfieren de forma transparente a DirectFB. Para Firefox, una es que usa X directamente a veces. Además, algunos elementos independientes del toolkit, como la interfaz del complemento del navegador, usan X directamente. El complemento de Flash no funcionaría en DirectFB, por ejemplo. Incluso las aplicaciones que no usan X directamente a menudo suponen que existe el entorno de escritorio normal basado en X (GNOME, etc.).
Otro problema con la sustitución de X es el soporte del controlador, donde las mejores tarjetas gráficas (NVidia, ATI) tienen controladores propietarios que son un poco más capaces que los controladores libres, y esos controladores propietarios están vinculados a X.
Y, por supuesto, hay una ruta de migración. Si tiene cientos de aplicaciones que usan X y ninguna desventaja clara del usuario final respecto a X, nadie va a cambiar a algo donde no funcionen las aplicaciones. Lo más probable es que la solución aquí sea un servidor X sin root que se ejecute en un nuevo sistema de ventanas, por lo que las aplicaciones antiguas aún funcionan.
Lo viejo no siempre es malo. X fue diseñado muy bien por gente inteligente, y eso le ha permitido evolucionar, cambiar y seguir funcionando muchos años después.
De todos modos, un largo camino de decir, básicamente cambiar de X significa mucho esfuerzo, realmente funciona bien, y "funciona bien" nunca se ha aplicado a ninguna de las alternativas (al menos si se quiere poder ejecutar la mayoría de las aplicaciones en la mayoría del hardware).
Existen problemas con X, como la imposibilidad de hacer una actualización de pantalla atómica, algo que el proyecto Wayland está mirando, pero la mayoría de los problemas son realmente cosméticos para los usuarios (por ejemplo, actualizaciones no atómicas) o cosméticos para desarrolladores (viejas extensiones obsoletas y similares). Simplemente no es cierto que uno pueda soltar X y mágicamente tener algo mucho más pequeño y más rápido. Esto se basa principalmente en personas que especulan que "viejo" y "usa la red" deben ser lentos e hinchados, pero una vez más, X fue diseñado para hardware verdaderamente horrible. Solía ejecutar X (¡y Emacs!) Bien en mi 386 con quizás 8 megas de RAM o algo así.
firefox no usa directamente Gtk +; solo usa su motor de temas. –