Lo primero a tener en cuenta, como bien comenta el artículo, es que las aplicaciones se programan (no ya que se compilen) para la API de X-Window System.
Más que un API, de lo que hablamos cuando decimos "X" o "X Window" es de un protocolo; que luego las aplicaciones cliente usen la biblioteca Xlib para hablarlo es "accidental". En freedesktop.org se nos propone XCB como alternativa a Xlib, pero una aplicación que enlazase con XCB seguiría mostrándose correctamente en XFree86 o en cualquier otro servidor X porque el protocolo que hablan los clientes sigue siendo el mismo (aunque cambie la biblioteca).
De hecho, esto de que las X es un protocolo es una de las cosas que la gente suele olvidar cuando pide tal o cual mejora del mismo. Modificar un protocolo estándar implementado por muchos fabricantes implica sentar a muchas personas a una mesa... O eso o echarte al monte y hacerte incompatible con los demás.
Existe, claro, el mecanismo de las extensiones para ampliar el protocolo, pero usando tus propias extensiones de lado del cliente corres peligro de que tu aplicación no corra más que en algún servidor X.
El problema principal de X-Window es la cantidad de tráfico que se genera entre el cliente y el servidor gráfico: prácticamente se envía el dibujo línea a línea y punto a punto [...]
Aparte de las funciones típicas de dibujado (arcos, líneas, puntos, fuentes, etc), habría que mencionar que también puedes transferir pixmaps... Que es lo que hace la práctica mayoría de las aplicaciones que corren hoy en día, con esos bonitos y pesados motores de temas basados en pixmaps y demás.
Esto es lo que hace que el sistema sea tan pesado, incluso en local, no digamos ya en red.
No, eso es falso. En ambos casos. Al menos en el caso de XFree86.
En local, todas las comunicaciones cliente/servidor se realizan vía socket Unix y por un socket Unix podemos mover fácilmente más de 100 Mega Bytes por segundo, al menos en Linux y con un PIII. No es tan rápido como llamadas a una biblioteca pero es bastante rápido. Por si esto fuera poco, los pixmaps no hay que enviarlos por el socket si el servidor soporta la extensión de memoria compartida (XFree86 la soporta): servidor y cliente pueden simplemente compartir esas páginas siempre que ambos corran en la misma máquina.
Este diseño, además, no es tan extraño. Windows NT funciona de forma bastante similar a X (whitepaper que explica los cambios de 3.51 a 4.0 al respecto "MS Windows NT Kernel-mode User and GDI White Paper"): existe un servidor gráfico, el subsistema GDI, que ofrece operaciones de dibujado casi idénticas a las de Xlib y las aplicaciones de usuario se comunican con el subsistema o bien por una rápida IPC ("Fast LPC", en versiones pre 4.0 de NT) o bien por medio de un trap (en versiones posteriores). Es cierto que, aparte de GDI hay un subsistema USER que se ocupa del dibujado de los widgets del gestor de ventanas, pero ese subsistema al final delega el dibujado en GDI y, al ser subsistemas diferentes, la comunicación vía IPC ha de hacerse de todas formas.
Si ese esquema funciona en NT, ¿por qué no debería funcionar en XFree86?. o mejor ¿por qué veo en mi casa que no funciona?. Para averiguarlo quizás habría que fijarse menos en lo que hace el servidor y más en los clientes.
Hablando del desempeño en remoto. El protocolo X está pensado para funcionar con enlaces con mucha latencia y ancho de banda normal, tirando a escaso para los tiempos que corren. Por ejemplo, en él está previsto que haya ventanas que no tengan que redibujarse, sino que se gestionen de forma local en el servidor ("gravity" y "backing store pixmaps") sin despachar innecesarios "expose events" a los clientes.
También se tiene en cuenta de que el 99% del protocolo es asíncrono, con lo que lo que se atenúa el efecto de la latencia del enlace.
Todo esto sobre el papel... En la práctica, las aplicaciones no toman ventaja de nada de esto. Ya he hablado alguna vez por aquí del soporte de Gtk+ de la gravedad (inexistente). Este toolkit también es bastante liberal en el uso de XInternAtom y familia (que pertenecen a ese 1% síncrono del protocolo) para la comunicación entre clientes, con lo que el efecto de la latencia se nota mucho más.
Otro problema de los toolkits "modernos" es que usan (y a veces abusan) de los pixmaps. Una debilidad de las X es que los pixmaps no se manejan comprimidos y, hoy por hoy, son casi siempre TrueColor. Si además de esto tenemos toolkits que no definen gravedad (obligando una y otra vez al redibujado de todas las ventanas), el problema se hace aún más patente.
Es decir, que muchas veces más que unas X lentas, lo que hay es un toolkit lento, programado pensando en algo que no eran las X, o una aplicación defectuosa. No es lo mismo correr en remoto una aplicación programada con FLTK (que usa una sola ventana para dibujar toda la aplicación, con lo que los eventos de redibujado se reducen muchísimo, y no usa temas pixmap) que en otro toolkits como Gtk+ o similar, por ejemplo.
¿Implementar lo anterior a la vez que se aligera y modulariza el propio servidor gráfico? Ésta me parece la mejor idea.
Si te refieres a XFree86, absolutamente todo el servidor es modular desde la versión 4. Puedes compilar todo como extensión y ponerl éstas y retirarlas a tu antojo. Puedes tener desde un XFree86 que consuma menos de cuatro megas de RAM hasta las 28 megas que me ocupa a mí ahora mismo sin ajustar nada en especial (bastante menos que Mozilla Firebird, por cierto).
En fin, que a veces XFree86 se lleva palos que no le corresponden. Es curioso porque no todos los días se ve un proyecto libre de esas dimensiones, hablando directamente con el hardware, bastante estable y con ese rendimiento (aunque esto último no lo parezca, claro :-)).
[ Padre ]
|
