Libertonia || Comments || El futuro del sistema gráfico


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

El futuro del sistema gráfico | 6 comentarios (6 temáticos, editoriales, 0 ocultos)

Protocolo X, XFree86, rendimiento, etc. (5.00 / 7) (#5)
por jorginius ("jorginius" en Google Mail) a las Fri Apr 23rd, 2004 at 01:01:28 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

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 ]

La latencia de los socket Unix (5.00 / 1) (#6)
por jorginius ("jorginius" en Google Mail) a las Fri Apr 23rd, 2004 at 09:44:48 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Se me olvidó comentarlo: aparte del ancho de banda de esa IPC, la latencia es del orden de los 100 us enviando paquetes de unos 50 KB. Un poco difícil de medir en todo caso.

Y Window también utiliza sockets Unix (o tcp, claro) para comunicar cliente con servidor. DirectFB no, pero DirectFB no pretende ser más que una biblioteca.

Por cierto, que hay varios proyectos que se llaman "Y Window": mala opción como nombre :-). Conocía el servidor X "Y Window", de los Hungry programmers (la gente de Lesstif y Japhar) pero también hay un entorno de ventanas texto "Y window" (tb transparente a la red).

[ Padre ]

El futuro del sistema gráfico | 6 comentarios (6 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda