graphics - todas - ¿Por qué DirectFB no se usa más ampliamente en GNU/Linux? ¿Existen limitaciones paralizantes que no existen en X11?
todas las versiones de linux que existen (6)
Según tengo entendido, DirectFB ofrece aceleración de hardware para muchos tipos de tarjetas gráficas. Además, es más pequeño, más rápido y consume menos memoria que X11. ¿Por qué entonces, no es más corriente de lo que es ahora?
Esto es de lo que realmente no estoy seguro: ¿Los programas comunes de GTK + / Qt necesitan ser adaptados a ellos? En el sitio de DirectFB, hay un proyecto para transferir Firefox a él. ¿Por qué es eso incluso necesario, si GTK + tiene la capacidad de usar DirectFB directamente? La forma en que (probablemente de manera incorrecta) lo entiendo, es que Firefox debería enviarse a GTK +, que debería generar a DirectFB, que debería enviarse al hardware. Por favor corrígeme si me equivoco al respecto.
Gracias,
Hassan
Con XDirectFB hay un servidor X sin root que usa DirectFB.
Si está haciendo hincapié en que X es 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 potentes que un teléfono celular moderno.
Si miras "top" y ves a X usando la memoria, hay mucho trabajo que hacer para averiguar la sobrecarga real de X. Hay mapas de memoria que no son memoria "real", y hay recursos (como grandes bloques de píxeles) asignados en nombre de las aplicaciones. En resumen, la memoria que se muestra para X en la parte superior no es lo que uno podría pensar.
La gente también escucha que X usa la "red" y piensa que esto va a ser un cuello de botella en el rendimiento. "Red" aquí significa un socket de dominio UNIX local, que tiene una sobrecarga insignificante en Linux moderno. Cosas que podrían causar un cuello de botella en la red, hay X extensiones para hacerlas rápidamente (pixmaps de memoria compartida, DRI, etc.). Los subprocesos 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 la coordinación de varios subprocesos o procesos que acceden al mismo hardware que con la sobrecarga mínima de los sockets locales.
La configuración de procesos múltiples tiene muchas ventajas, como ser mucho más difícil de bloquear. Vea Google Chrome, por ejemplo, usando varios procesos para ser más robusto, y resulta que también se ejecuta rápidamente. Menos procesos no significa necesariamente más modernos.
Hay muchas razones por las que las aplicaciones que usan GTK no se transfieren de manera transparente a DirectFB. Para Firefox, una es que usa X directamente a veces. Además, algunas cosas independientes del kit de herramientas, como la interfaz del complemento del navegador, usan X directamente. Flash plugin no funcionaría en DirectFB por ejemplo. Incluso las aplicaciones que no usan X directamente a menudo asumirían que existe un entorno de escritorio basado en X normal (GNOME, etc.).
Otro problema con la sustitución de X es la compatibilidad con controladores, donde las mejores tarjetas gráficas (NVidia, ATI) tienen controladores propietarios que son un poco más capaces que los controladores gratuitos, 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 no tiene un usuario final claro a la desventaja de X, nadie cambiará a algo en el que no funcione ninguna aplicación. 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 estaba muy bien diseñado por personas inteligentes, y eso le ha permitido evolucionar y cambiar, y sigue funcionando muchos años después.
De todos modos, todo un largo camino para decirlo, básicamente alejarse de X es un montón de esfuerzo, realmente funciona bien y "funciona bien" nunca se ha aplicado a ninguna de las alternativas (al menos si desea poder ejecutar la mayoría de las aplicaciones en más hardware).
Hay problemas con X, como la imposibilidad de realizar una actualización de pantalla atómica, algo que el proyecto Wayland está analizando, pero la mayoría de los problemas son realmente estéticos para los usuarios (por ejemplo, actualizaciones no atómicas) o estéticos para los desarrolladores (extensiones antiguas en desuso). 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. Eso se basa principalmente en personas que especulan que "antiguo" y "usa la red" deben ser lentos e inflados, pero, de nuevo, X fue diseñado para hardware realmente horrible. Solía ejecutar X (y Emacs!) Bien en mi 386 con quizás 8 megas de RAM o algo así.
Simple, porque DirectFB no resuelve ningún problema. Para los sistemas integrados está bien, pero para el escritorio, se pierde mucho y realmente no se gana nada.
X11 es mucho más portátil que DirectFB. Una aplicación X11 puede ejecutarse en Linux, BSD, Solaris, AIX, HP-UX, MacOS X, Windows (a través de Cygwin o Exceed), y muchas más plataformas. DirectFB es prácticamente solo para Linux.
x11 es mucho más que una forma de dibujar en una pantalla: es un conjunto completo de protocolos de escritorio con capacidad de red. DirectFB no tiene la intención de reemplazar x11 (que yo sepa), sino que corre paralelo a él. Es decir, DirectFB se esfuerza por ser un "host" ligero para las aplicaciones que necesitan acceso a la entrada básica y la salida gráfica. Es posible que un servidor X (el servidor en X es lo que muestra cosas :-) esté escrito para usar DirectFB.
DirectFB fue diseñado para sistemas embebidos, que tienen una pequeña huella de memoria. Permite que las aplicaciones hablen directamente al hardware de video a través de una API directa, acelerando y simplificando las operaciones gráficas.
A menudo es utilizado por los desarrolladores de juegos y sistemas integrados para evitar la sobrecarga de una implementación completa del servidor X Window System.