El Sistema X Window. Tercera Parte: Nuevas Tecnologías en X
Agosto 9 de 2.004
Por Manuel Alejandro Cerón Estrada.
Contenido |
Introducción.
Esta es la tercera parte de la serie de artículos sobre el Sistema X Window. En la primera parte, hablé un poco sobre las generalidades y características originales de X; en esta ocasión, voy a hablar acerca de algunas extensiones y características que han surgido en los últimos tiempos y que, gracias a la flexibilidad de X, traen las últimas tecnologías al sistema. Obviamente no puedo nombrar todas las nuevas características y extensiones, pero trataré de mencionar las más sobresalientes.
DRI y Mesa
Como se había mencionado en la primera parte de esta serie de artículos, El Sistema X Window esta basado en una arquitectura cliente-servidor. El diseño de X está pensado para que los clientes no tengan que saber nada acerca del hardware de vídeo o de como la información es representada en pantalla. El servidor abstrae toda la información de bajo nivel, y se comunica con el cliente mediante mediante el Protocolo X, el cual representa un camino delgado que puede trabajar sobre otros protocolos como TCP/IP. Esto conlleva grandes ventajas para X, como por ejemplo el hecho de poder ejecutar aplicaciones remotamente, entre otras. No obstante, también representa un inconveniente, el cual tiene que ver con las aplicaciones gráficas de alto rendimiento, por ejemplo los vídeojuegos 3D en tiempo real y aplicaciones multimedia. El problema consiste en que el sistema de comunicación entre el cliente y el servidor, siguiendo el Protocolo X, es relativamente lento; es como la parte angosta de un reloj de arena. Para la mayoría de aplicaciones GUI este no es un problema, debido a que no tienen que enviar muchos datos gráficos al mismo tiempo, sin embargo, cuando se quiere hacer uso de 3D en tiempo real, todo cambia, las cosas se tienen que hacer muy, pero muy rápido. Lo más recomendado en estos casos es tener acceso directo al hardware desde el cliente, pero esto es precisamente lo que el diseño de X trata de evitar.
Con el fin de solucionar el problema del acceso directo al hardware con X, nació el Proyecto DRI (Infraestructura de Renderizado Directo por sus siglas en ingles). DRI es “un framework para permitir el acceso directo al hardware gráfico de forma segura y eficiente”. La forma en que DRI funciona consiste básicamente en cambiar la librería Xlib para que desvíe los datos, que normalmente se dirigen hacia el servidor X, hacia un controlador del kernel que puede acceder directamente a la tarjeta de vídeo. De esta forma el cambio es transparente para los desarrolladores de aplicaciones. Uno de los objetivos de DRI es ayudar a la creación de una implementación de OpenGL acelerada por hardware. Este objetivo se está cumpliendo gracias a la cooperación con el Proyecto Mesa[1].
Brian Paul comenzó el desarrollo de Mesa en 1993 como un pequeño proyecto para sus ratos libres, el objetivo era crear una librería de gráficos 3D que cumpliera con el estándar OpenGL y que fuera Software Libre. Como es común en los proyectos libres, rápidamente se unieron muchas personas para colaborar en su desarrollo y el proyecto se convirtió en algo gigantesco, llegando a ser la implementación de OpenGL más importante para GNU/Linux. Con la ayuda de DRI, Mesa pudo hacer uso de las tarjetas aceleradoras 3D para conseguir imágenes en tiempo real mucho, pero mucho más fluidas.
DRI y Mesa empezaron a ser parte de XFree86 desde la versión 4.0. Gracias a esto, se logró tener soporte para varias de las tarjetas aceleradoras 3D más modernas. Por fin fue posible el uso de juegos 3D avanzados[2], aplicaciones de modelado y animación e incluso se logro aumentar de forma considerable el desempeño de las aplicaciones GUI tradicionales. Definitivamente se convirtieron en una parte fundamental del Sistema X Window.
MAS
X fue diseñado exclusivamente para manejar la representación gráfica y los dispositivos de de entrada y salida como ratón y el teclado. Sin embargo, los computadores modernos poseen nuevos elementos que no existían comúnmente en los años en los que se creo X, como por ejemplo, la multimedia. Actualmente se está desarrollando un sistema de soporte para integrar otro tipo de componentes como audio y vídeo al Sistema X Window, haciendo uso de las mismas características de X: arquitectura cliente-servidor, transparencia en redes, portabilidad y, por su puesto, libertad[[[#Referencias|3]]]. El proyecto se llama MAS (Servidor de Aplicaciones Multimedia por sus siglas en ingles) y está patrocinado por la [http://www.x.org Fundación X.org]. Actualmente, MAS se encuentra en activo desarrollo y tiene miras a ser usado en escritorios como GNOME y KDE. Gracias a MAS va a ser posible, por ejemplo, tener servidores multimedia, con gran poder de procesamiento, que ejecuten reproductores de música y vídeos, aplicaciones de teleconferencia, “streaming” y juegos 3D. Y los clientes harán uso de todos estos servicios, sin gastar muchos recursos de hardware.
Xinerama
Normalmente, el Sistema X Window puede
manejar varios dispositivos de visualización, o “displays”.
Esto quiere decir que es posible usar varios monitores al mismo
tiempo para visualizar la información. No obstante, cada
monitor es tratado como un dispositivo diferente, haciendo, por
ejemplo, imposible pasar ventanas desde un monitor hasta otros, entre
otras cosas. Para solucionar este problema, surge el proyecto
Xinerama.
Xinerama es una extensión de X que permite que
varias pantallas físicas sean tratadas dentro del servidor
como una sola pantalla más grande. Gracias a esto es posible,
por ejemplo, crear una pantalla gigante a base de varios monitores
colocados de forma conjunta; algo así como un mosaico. Para
poder hacer uso de Xinerama, es necesario disponer de varias tarjetas
de vídeo (o una que soporte varios monitores), y por supuesto
varios monitores. La extensión Xinerama fue integrada por
defecto en XFree86 4.0.
Referencias
[1] Mesa no pudo llamarse públicamente una implementación de OpenGL, debido a problemas de licenciamiento. Para realizar una implementación oficial de OpenGL, es necesario obtener una licencia, bastante cara, de la ARB (Junta de Revisión de Arquitectura) de OpenGL. Obviamente el proyecto de Paul no tenía los recursos para eso y simplemente tuvo que declarar su proyecto como algo parecido a OpenGL, pero que no es una implementación. En realidad vendría siendo una implementación no oficial.
[2] Antes de DRI, la única forma de Juegos 3D avanzados que se podía ver en GNU/Linux, era aquella que utilizaba implementaciones propietarias como las de nVidia.
[3] Aunque está libertad no se
exactamente en el sentido de GNU (http://www.gnu.org/philosophy),
debido a que no posee copyleft.
El contenido del material publicado por nuestros columnistas es responsabilidad de sus autores.
Para saber más sobre la programación y naturaleza de nuestros artículos y columnas, haga clic aquí.
