Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
¿qué versión de X usas?

4.2.x   4 votes - 3 %
4.3   57 votes - 45 %
4.4   9 votes - 7 %
La que venga en mi distro   45 votes - 35 %
Mi mundo es la consola   11 votes - 8 %
 
126 Total Votes
Ver: Modo: Orden:
El futuro del sistema gráfico | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
El futuro del sistema gráfico (4.00 / 2) (#2)
por Envite a las Tue Apr 20th, 2004 at 04:25:12 PM CET
(Información Usuario)

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. Los nuevos proyectos tendrían que crecer mucho para que se programara para ellos, o bien usar una API compatible.

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, en lugar de enviarse directivas de dibujo de alto nivel o, incluso, componentes del dibujo. Esto es lo que hace que el sistema sea tan pesado, incluso en local, no digamos ya en red.

Esto tiene una solución sencilla (sencilla de decir, no necesariamente de programar): crear protocolos de mayor nivel en los cuales el servidor gráfico pueda tener almacenados el aspecto y la funcionalidad de los "widgets", disminuyendo así enormemente el tráfico.

Esto, en general, haría que X-Window corriese mejor en remoto, pero a la vez hace más pesado el programa en local.

¿Implementar lo anterior a la vez que se aligera y modulariza el propio servidor gráfico? Ésta me parece la mejor idea.

Todo lo anterior es independiente de qué grupo o grupos hagan el trabajo, sea freedesktop.org o el grupo de Xfree.
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire



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 ]


 
Al final no va a ser mala cosa (3.50 / 2) (#3)
por man ls a las Wed Apr 21st, 2004 at 12:06:05 AM CET
(Información Usuario)

El cambio de licencia de XFree86 está estimulando la aparición y popularización de alternativas. Como parece que la gente lleva tiempo quejándose de lo pesado que es X Window, es un buen momento para que se actualice la arquitectura -- y la nueva licencia puede ser el empujón que hacía falta. ¿No os parece?

La mejora que propones (que los widgets estén almacenados en el servidor) no lleva a cambios tan dramáticos como podría pensarse: la mayoría de programas no necesitarían modificaciones, ya que usan de todas formas librerías de widgets -- sólo necesitarían modificaciones las propias librerías. A mí me parece muy buena idea. ¿Hay alguien que esté trabajando en ello?

[ Padre ]


Server side widgets (4.50 / 2) (#4)
por neuralgya a las Wed Apr 21st, 2004 at 09:18:43 AM CET
(Información Usuario) http://worldspace.berlios.de

y-windows aborda este problema. Y-windows sería un buen sucesor de X:

- Server-side widgets
- Soporte Unicode
- True 32bit alpha-blending (esto es sombras y transaparencias)
- Hot-pluggable module system for video, input and ipc drivers (oséase, cambio de drivers al vuelo)

De entre todas las alternativas comentadas en el artículo, para mí y-windows sería teóricamente la mejor. Un código nuevo, limpio y modularizado _desde el principio_. Pero habia que reimplementar Qt o GTK para este nuevo servidor.



------------------------------------ No soy adicto a la red, sólo formo parte de ella
[ Padre ]


 
Yo uso 4.4.0 RC 2 (3.00 / 2) (#1)
por man ls a las Tue Apr 20th, 2004 at 12:30:09 AM CET
(Información Usuario)

Aunque técnicamente es la 4.3.99.902, no deja de ser una 4.4 -- cosa que me tiene confuso sobre qué poner en la encuesta.

Pero es porque Mandgggake Cooker me obligó a instalarlo, cuando me actualicé a KDE 3.2. Yo estaba, la verdad, tan feliz con mi 4.3 -- no le veía problemas, salvo que mi tarjeta (integrada en placa) SiS 351 no soporta aceleración gráfica. Y eso no se ha solucionado, claro.

En ese aspecto, sólo puedo expresar mi disgusto hacia SiS, que no hace drivers abiertos para mi tarjeta. Y, por supuesto, mi agradecimiento a Thomas Winischhofer, autor y mantenedor oficial del driver para mi tarjeta. Por cierto que el tipo ya ha actualizado la página: dice que el mismo controlador (driver) soporta XFree86 y X.org, como se afirma en el artículo de arriba.



 
El futuro del sistema gráfico | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
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