Xgl y la revolución gráfica en Linux

Mucho se ha hablado sobre Xgl este ultimo tiempo, y pareciera que todos quieren instalarlo en sus escritorios, pero también veo que hay mucha confusión acerca de que se pretende con Xgl, incluso algunos creen que es una suerte de 3ddesktop pero más espectacular. Hace tiempo que quería escribir sobre el tema, y podría haber escrito varios artículos, pero como la próxima semana no voy a tener mucho tiempo, decidí escribirlo todo en uno solo. Sé que esto llegará a Planeta GNOME Hispano en donde hay gente que sabe mucho más del tema, agradezco si me envían correcciones al artículo por mail privado.

X-Server

El sistema gráfico utilizado en Linux es X-Window, este sistema asume que las aplicaciones actúan como un cliente (x-client) de un servidor X-Window (x-server). El x-server se encarga de lograr la interacción entre el usuario y la aplicación, el rol del servidor es desplegar la imagen en pantalla, y recibir los eventos de teclado, mouse y otros dispositivos. Hay distintas implementaciones de x-servers, los hay para Linux, MacOSX y también para Windows.

Mientras mejor sea el x-server, mejor es la representación de la aplicación. Para ir mejorando un servidor x-server se van proponiendo extensiones (x extensions) y con el tiempo estas extensiones se van implementando en los distintos x-server y drivers. Ejemplos de x-server son XFree86 y Xorg.

Aunque normalmente tanto los x-client y el x-server se ejecutan en un mismo computador, la separación entre x-client y x-server también permite que una aplicación que se ejecuta en un computador, pueda utilizarse desde otro computador en forma remota con un x-server corriendo en el computador local al usuario en forma independiente del sistema operativo.

X Server y X Clients
X Server y X Clients

Modelo de composición

El dibujado de las aplicaciones en pantalla se llama composición. En los sistemas tradicionales, cada ventana es un rectángulo en donde se dibuja la aplicación. Cuando una ventana cubre a otra, no es necesario dibujar el contenido de la ventana no visible. Cuando una ventana que cubre a otra se mueve, la nueva superficie visible de la ventana debe ser redibujada por la aplicación. Si ustedes mueven una ventana en el escritorio rápidamente, verán como las aplicaciones intentan redibujar las ventanas. Este es el modelo de composición utilizado tanto en Windows como en Linux

Una de las desventajas es que las aplicaciones constantemente tienen que estar redibujando las ventanas aunque no hayan sufrido cambios. Si la aplicación no responde, lo único que veremos sera un rectángulo vacío, o si la aplicación se demora en redibujar, se verá un retraso en el despliegue. Otra desventaja es que una ventana que quiera utilizar áreas no rectangulares o áreas semitransparentes, tienen «conciencia» limitada de lo que esta dibujado detrás de ellas, por lo tanto cualquier ventana que no sea 100% opaca y rectangular, no se dibujará correctamente. Si han visto como funcionan gDesklets o SuperKaramba, entenderán de lo que estoy hablando.

Comparación entre modelos de composición
Comparación entre modelos de composición

Composite Managers : xcompmgr, luminocity, looking glass

Un modelo de composición mas evolucionado consiste en dibujar las ventanas completamente fuera de pantalla (off-screen). Cada aplicación dibuja solamente cuando necesita cambiar algo de su ventana, y el contenido completo de cada ventana siempre está disponible, aunque no sea visible. Una aplicación especializada se encarga de transferir la imagen de cada ventana al área visible de video, es decir al escritorio que vemos en pantalla. En esta transferencia puede aplicar cualquier transformación, por ejemplo cambiar el tamaño, rotar, mezclar con el fondo, etc. Esta aplicación especializada es lo que se conoce como Composite Manager. Mientras que un Window Manager debe posicionar y manipular (move/resize) las ventanas en el escritorio, un Composite Manager se encarga de renderizar las ventanas en el escritorio.

Un Composite Manager radical podría por ejemplo dibujar las ventanas como una textura sobre un polígono a través de OpenGL, y pedirle a la tarjeta de video que dibuje el polígono en pantalla, considerando que hoy en dia las tarjetas de video son hábiles en renderizar polígonos en un entorno 3D, se podría delegar gran parte del trabajo a una tarjeta con aceleración 3D. Si por ejemplo se quisiera obtener una vista minituarizada o ampliada de la ventana, bastaría simplemente con cambiar el tamaño del polígono y la tarjeta de video se encargaría de hacer el render, y Uds. saben: «sí, son rápidas». Al mover una ventana sobre otra, son simplemente dos polígonos que se superponen, y se pueden mover «como si nada».

Keith Packard trabajó en una nueva x-extension llamada Composite. Esta extensión permite cambiar el modelo de composición tradicional en donde cada ventana dibuja solo las áreas visibles, y redibuja las que se van «descubriendo», por el descrito en el párrafo anterior en donde las ventanas se dibujan siempre off-screen. El trabajo se inicio en el x-server experimental kdrive, también conocido como el x-server de freedesktop.org, y posteriormente se implementó en el servidor Xorg, que es el que viene con la mayoría de las distribuciones de Linux. Hay un paper sobre los cambios necesarios para cambiar al nuevo modelo de composición.

X Server de FreeDesktop
X Server de FreeDesktop

El primer Composite Manager conocido se llama xcompmgr, y era un Composite Manager de ejemplo que implementaba cosas simples como agregar sombras y transparencias a las ventanas. Para realizar estas sombras y transparencias se utilizaron funciones de la extensión XRender (también de K.P.), un obstáculo es que prácticamente ningún driver de Xorg acelera(ba) correctamente la extensión XRender, a excepción del driver propietario de nvidia. El problema es que la arquitectura de aceleración de Xorg (XAA) no es muy adecuada para tener XRender acelerado por hardware, mientras que la arquitectura de kdrive (KAA) si permite una buena implementación de XRender pero no hay muchos drivers compatibles con kdrive. Por lo tanto, xcompmgr solo era usable si eras propietario de una nvidia, o bien utilizabas kdrive pero sin aceleración por hardware.

Para solucionar este problema, surgió la iniciativa de EXA, que vendría siendo algo así como KAA aplicado a Xorg. La idea era que lentamente los drivers XAA se fueran convirtiendo en EXA, y el usuario puede escoger si usar EXA o el modelo tradicional XAA. Mientras tanto, en RedHat se comenzó a experimentar modificando Metacity, que es el Window Manager de GNOME, para que incluyera funciones de un Composite Manager. Este desarrollo tomo el nombre de Luminocity. Este Composite Manager era mas ambicioso que xcompmgr e incluía funciones de transformación de ventanas, uso inteligente de transparencias para destacar ventanas en transición, y un selector de escritorios en donde se podia ver cada ventana minituarizada en tiempo real.

Luminocity
Luminocity

Si buscamos otra aplicación de Composite conocida, tenemos el famoso proyecto Looking Glass de Sun. Ellos aprovecharon la extensión composite para poder hacer un Window Manager/Composite Manager que pudiera manipular las ventanas en un entorno 3D.

Looking Glass de Sun Microsystems

Xgl y Compiz

Otro camino posible para obtener buenos resultados era olvidarse de Xorg y crear un nuevo x-server que facilitara el trabajo considerando el nuevo modelo de composición, y aprovechando las características de las tarjetas de video modernas que han sido diseñadas para utilizar operaciones gráficas 3D aceleradas por hardware. Es ahi donde aparece el x-server Xgl, publicado recientemente por Dave Reveman de Novell. Este x-server realiza sus operaciones de render no utilizando un driver propio, sino que utilizando un driver OpenGL. El x-server Xgl mas común es el Xglx, y lo que hace es conectarse a otro servidor X que tenga soporte de OpenGL a través de la extensión GLX (OpenGL/X). Entonces si levantamos Xorg + Xglx tendremos un x-server con operaciones OpenGL aprovechándose de la infraestructura de otro x-server con drivers OpenGL a través de GLX. Es esta combinación la que hemos tenido oportunidad de ver últimamente en los alucinantes videos.

El Composite Manager creado para aprovechar las características de Xgl se llama Compiz, además de ser un Composite Manager también es un Window Manager. Una de las cosas interesantes de Compiz es que funciona en base a plugins, entonces cada plugin agrega un nuevo efecto especial a Compiz. Los plugins que existen a la fecha permiten hacer fade de las ventanas al aparecer/desaparecer, rotar los escritorios virtuales como un cubo, visualizar las ventanas como Exposé de MacOSX, mover las ventanas como si fueran de papel. etc.

Xgl + Compiz
Xgl + Compiz

Aiglx y Xair

No todos eran partidarios de construir un nuevo x-server como se hizo con Xgl, porque era harto trabajo. Entonces surgió un proyecto alternativo llamado Aiglx, publicado por RedHat. Aiglx permite utilizar aceleración OpenGL para realizar la composición, pero modificando suavemente Xorg. Aiglx se apoya en un Composite Manager llamado Xair, que al parecer es una evolución de Luminocity.

Soporte de Hardware

Para utilizar el nuevo modelo de composición en nuestros computadores, necesitamos hardware que sea compatible con las distintas combinaciones de x-servers y composite managers. Hoy en día la mejor alternativa es utilizar alguna tarjeta de video que utilice un chip de nvidia. El soporte va a ir mejorando a medida que se implementen las funciones necesarias por cada x-server y composite manager, específicamente el soporte de EXA, y la nueva extensión GLX_EXT_texture_from_pixmap son claves para la expansión de estas nuevas tecnologías.

El cambio en la forma en que se perciben las ventanas, y el hecho de que las aplicaciones ya no tienen que redibujar, hacen que el cambio realmente valga la pena, inclusive si solamente se utiliza xcompmgr en su forma mas básica.

Las esperanzas son altas, por ejemplo tengo una tarjeta de video integrada Intel i855 de 64MB, xcompmgr funciona perfectamente con Xorg, es suficientemente usable como para tenerlo diariamente en mi escritorio. Compiz+Xgl funcionan bien, pero con algunos «glitches», y hay cosas que funcionan lentas debido a la falta de soporte de GLX_EXT_texture_from_pixmap en la versión actual de mi driver.

¿Como estan los otros sistemas?

MacOSX cambió el modelo de composición hace bastante tiempo, a través de Quartz Extreme . Windows cambiará el modelo de composición en Windows Vista, pero requerirán un hardware mucho mas potente para poder aprovechar estas características.

Linux, GTK y GStreamer en dispositivos moviles

PalmSource ha anunciado hoy una nueva plataforma llamada ALP, que significa Access Linux Platform.

Esta plataforma está basada en Linux (2.6.12) y contiene otros componentes opensource como son GTK+ y GStreamer, el primero es el toolkit de GNOME, y el segundo es un framework multimedia, ambos muy populares en el mundo de Linux.

Esta sería la segunda plataforma movil con planes de extenderse a gran escala, anteriormente Nokia publicó Maemo, también basado en componentes open source (Linux/GNOME) y que ya utiliza en su Nokia 770. Una de las cosas más interesantes de ambas plataformas es que cualquier programador con conocimientos básicos de C y GTK puede realizar aplicaciones para ellas, por ejemplo al ver el tutorial de Maemo se ve que es suuuper facil escribir buenas aplicaciones.

Seguramente Max, que justamente se encuentra en la 3GSM nos contará más sobre este anuncio, y también estoy seguro de que esto será buen material para la memoria que esta escribiendo en estos momentos mi amigo Frisco, cierto? 😉

No es tan simple!

En los comentarios de mi artículo anterior sobre el video de Xgl, mi amigo Sebastian Beeche plantea algunas dudas que son muy frecuentes entre los usuarios de Linux y que muchos se autoresponden en forma equivocada o simplemente no consiguen respuesta. Lo que voy a comentar aqui lo hago desde lo que me ha tocado conocer, tanto desde el punto de vista de desarrollador, como el de un simple mortal suscrito a listas de desarrollo, asi que no lo tomen como «la verdad», solo como lo que he observado.

Seba: «Para que Linux sea realmente LA alternativa, además de mejorar la gráfica, hay que hacer que el sistema sea más amable con todo tipo de periféricos».

Esto NO es posible asi como estan las cosas. Linux no va a tener soporte de todo el hardware sin la cooperación de los fabricantes de hardware. Para que un dispositivo pueda ser soportado en Linux se necesita de un driver, y para que exista un driver se debe cumplir una de las siguientes condiciones

  • El fabricante desarrolla el driver para Linux
  • El fabricante entrega las especificaciones del hardware para que un tercero desarrolle el driver para Linux
  • Un tercero, mediante ingeniería inversa, deduce las especificaciones del hardware y escribe su driver para Linux

Salvo honrosos casos, los fabricantes no desarrollan drivers para Linux. Esto tiene diversas explicaciones, una de ellas es no contar con los recursos y/o el know-how de cómo escribir un driver para Linux… y hay que decirlo.. con suerte hacen el driver para Windows, no es raro que el driver para Windows sea muy malo, con mayor razon poco les queda para otros sistemas. Otra explicacion es la masa critica : muchos de ellos esperan que hayan mas usuarios utilizando Linux, mientras que los usuarios esperan a que el fabricante desarrolle los drivers, en esas condiciones es muy dificil que el fabricante desarrolle el driver.

Ok, si el fabricante no desarrolla el driver, entonces por que no entrega las especificaciones? Aqui siempre es el mismo caso, hay un temor del fabricante de revelar «los secretos» de su hardware, estos secretos consideran tanto tecnología que no desean publicar asi como tambien mejoras que se hacen en los drivers para que el hardware se comporte mejor en ciertos tipos de benchmark conocidos. Otro motivo para no entregar las especificaciones es el licenciamiento de tecnologías de terceros, que impide a un fabricante revelar como funciona el 100% del hardware.

Queda entonces una sola alternativa, tratar de adivinar cómo funciona el hardware, pero esta es tan costosa como imposible, ademas que es muy poco el beneficio versus el esfuerzo. Te puedes demorar 1 año en aprender como funciona el 5% de un cierto tipo de hardware, que despues sera desplazado por otro. Por eso si el hardware no tiene driver, es mejor botarlo a la basura o prenderle fuego.

Seba: «No se xq Linux se ha demorado tanto en ese paso final, cuando la gente de Jobs lo sacó en un plazo de un par de años siendo que son un grupo pagado pero MUCHO más reducido que la comunidad total de gente que aporta a Linux»

No es tan asi. Si bien el grupo de gente involucrada con el desarrollo de Linux es muy grande, esta distribuido en muchos proyectos, por lo tanto cada proyecto cuenta con un grupo no tan numeroso de gente (kernel, gcc, Xorg, GNOME, KDE, OpenOffice, etc). Por ejemplo los desarrolladores principales de OpenOffice no son mas de 15, el resto son personas que contribuyen ocasionalmente. Si quieren ver la gente que trabaja en GNOME, y donde viven, pueden ver el mapa de desarrolladores de GNOME, ahora dividan por el número de proyectos que conforman GNOME. Por eso se hace tanto énfasis en las RFDG.

El hecho de que sea un grupo pagado también cambia harto las cosas, te aseguras de que puedan dedicarse 100% al tema. Actualmente en Linux los principales desarrolladores son pagados, pero todos son independientes entre si, no hay una «orden superior» que señale una senda a seguir, sino que todo se debe discutir y acordar, y ponerse de acuerdo no es tan facil. Es quizas una de las principales complicaciones cada vez que se quiere hacer un cambio grande, por lo mismo los grandes avances a veces se han desarrollado sin preguntar mucho a los demas, de paso se evita el fenómeno de Stop Energy.

Si lo llevamos al tema de los drivers, para Apple es un tema mucho mas facil de resolver, simplemente si quiere incluir un tipo determinado de hardware a su propio hardware, puede financiar el desarrollo negociando directamente con el fabricante del hardware y listo. Total el fabricante de hardware se esta jugando la venta de su hardware como parte de las maquinas de Apple, o por ultimo como periférico compatible.

A nivel de software, algo similar esta haciendo Novell mediante una encuesta para saber que aplicación podría portarse a linux llegando a un acuerdo directamente con sus desarrolladores originales.

Seba: «Ahora, siendo super honestos, hay 3 tarjetas de video en el mercado (Ati, Nvidia e Intel) y con eso de más que se puede dar un soporte digno»

Actualmente Nvidia desarrolla un driver para Linux ocultando su código fuente para evitar problemas legales como los mencionados arriba. Su driver es 100% funcional y el soporte es tan bueno como en Windows. Ellos anteriormente habian donado un driver opensource pero esta bastante recortado, por motivos legales solo implementa lo que se podia publicar, además que está intencionalmente ofuscado. El problema es que hasta no hace mucho, nvidia era muy bueno haciendo hardware, pero muy malo escribiendo drivers para Linux, lo que causaba que a muchos usuarios se les colgara el sistema por bugs del driver. Y como no son open source, nadie los puede corregir salvo nvidia. Hoy en dia la situación es muy distinta, y si alguien me pregunta por qué tarjetas de video son las mejores soportadas en Linux, mi respuesta es nvidia. Por ejemplo, su driver propietario con aceleración de la extensión RENDER por hardware hizo posible que xcompmgr funcionara super bien desde el principio, y no me extrañaría que los videos de la demo estén utilizando hardware de nvidia, o bien otro hardware pero con driver que utilice EXA.

En ATI no me queda muy clara la situación. Ellos también tienen una mezcla entre propietario y open source. Hay un driver propietario, que aprovecha casi el 100% el hardware pero que tiene problemas con bugs. También han cooperado para que se puedan escribir drivers open source aunque no se aproveche 100% su funcionalidad. Según entiendo, ellos han ayudado en la construcción del driver open source para sus chips, mediante acuerdos directos entre ellos y algunos (o un) desarrollador(es).

El caso de intel es similar, pero sin driver binario. No puedo decir mucho de esos drivers, mi notebook los usa pero no tengo como compararlo con el de windows (tarea para mas adelante).

Seba: «El sistema de apple de como maneja la data, las instalaciones, los programas y las opciones de usuarios son realmente buenas, en las que hasta un diputado podría hacer uso de ellas (bueno.. no se si tanto 😀 )»

No puedo comentar mucho, porque no conozco como funcionan estas cosas en MacOSX. Pero si puedo decir que al menos en una buena distribución (como Ubuntu), el tema de la instalación de aplicaciones es lo mas sencillo que he visto, siempre y cuando sean aplicaciones open source. Y cuando no son open source, la responsabilidad es unicamente del desarrollador de software, ya que las herramientas para empaquetar, instalar y publicar existen, son de libre uso y son simples de utilizar, si «hasta el Bruno las sabe usar» ;). En Linux cualquier aplicación es simple de instalar siempre y cuando exista un paquete para ella.

Sobre el manejo de «la data» no se a que se refiere exactamente Sebastián, y sobre las opciones de usuario tampoco se que calificaría como «buena», como para ver en que estado esta Linux.