[eside-ghost] Compilando Xgl

[Jon Ander Hernández]

Aupi a todos!!

On jue, 2006-02-09 at 21:00 +0100, Saladino wrote: 
> Yo soy poco amigo de el mariconeo de pantalla, pero ese video me ha
> dejado O_______O y viendo que andas por aqui te voy a fusilar un
> poquillo, jejej.

xDDDDD

La verdad es que los videos son muy acojonantes, y supongo que aunque a
uno no le guste el mariconeo de pantalla y piense que puede vivir sin
ello, la verdad es que son cosas que le van a molar a todo el mundo. Ya
se, ya se que me vais a decir algunos que pffff... pero el expose de OSX
es muy cómodo cuando tienes un porrón de navegadores abiertos y ya no
recuerdas dentro de cual tenías tal página.

> Este tema del xgl luego hay que implementarlo en el gestor de ventanas
> tmb? Quicir, yo uso IceWM ahora(he dejado Gnome solo pa casa), me
> imagino que por mucho que use Xgl y polleces de esas si IceWM no
> implementa nada de eso me quedo con las ganas no?

Yep. Aunque bueno la cosa es un poco más compleja y para más inri se ha
complicado más aún xDDD.

Lo primero de todo antes de meternos en temas de las X, gnome es un
desktop y no un gestor de ventanas, metacity es su gestor de ventanas
por defecto, pero es totalmente reemplazable por cualquier gestor de
ventanas compatible con el freedesktop.org "window manager spec", osea
que lo podemos cambiar por kwin (el gestor de ventanas de kde),
Enlightenment, xfwm (el de xfce), blackbox... IceWM parece ser que no es
totalmente compatible con este standard por lo que igual no te funciona
bien con Gnome (y donde digo gnome digo kde, xfce o incluso el eterno
olvidado GnuStep).

Para entender bien las cosas voy a explicar un poco que es un gestor de
ventanas. En las X como alguno habrá sospechado existe la curiosidad de
que excepto las X todo el reemplazable, podemos usar varios toolkits
como por ejemplo tk, openmotif, qt, gtk+, fltk... vamos que esto en el
resto de sistemas no es lo habitual, si tu desarrollas en
windows/macos/beos aunque no se te obligue a usar sus controles lo
normal es usarlos, pero en el mundo de las X se considera bueno y
correcto separar el sistema que aporta las operaciones gráficas del
programa/librería que pinta los controles.
Esto también se aplica a los gestores de ventanas, los gestores de
ventanas son un programa especial cuya misión es controlar el
comportamiento de las ventanas de las aplicaciones abiertas. El que este
programa sea reemplazable tiene su gracia y a la gente le gusta :)).
Entonces el gestor de ventanas hace varias cosas, lo primero gestiona
los eventos y se los manda a la aplicación que tenga el foco, por otro
lado dibuja las decoraciones de las ventanas y los botones, y por último
le dice a cada aplicación cuando se tiene que volver a pintar (por
ejemplo en caso de que otra ventana la haya ocultado hasta ahora y ahora
se vuelva a tener que ver).
El problema viene que este diseño tiene sus problemas el más conocido es
que cuando mueves una aplicación encima de la otra, la de debajo
parpadea porque se redibuja. Aparte es imposible con este sistema hacer
cosas como transparencias y también es muy difícil hacer corrección de
color. Entonces cuando se diseño Composite que lo que hace es permitir
que el contenido de una ventana se guarde en un buffer, se pensó... vale
vamos a inventar lo que se llama el gestor de composición. El gestor de
composición lo que hace es implementar el dibujo de los bufferes de las
ventanas para formar la pantalla. Osease pilla los contenidos de cada
ventana y los pinta en una superficie resultante. Si cambias de gestor
de composición pues lograr el efecto que tu deseas.
Por lo tanto en los primeros diseños lo que se hace es tener por un lado
el gestor de ventanas y por otro lado el gestor de composición.
Esto supone tener corriendo metacity y xcompmgr por ejemplo. Lo que
ocurre es que algunos gestores de ventanas como kwin (el de kde) y xfwm
(el de xfce) incorporan dentro del gestor de ventanas el propio gestor
de composición, con lo cual no necesitas el xcompmgr.
Por cierto que no lo he dicho, xcompmgr es el primer gestor de
composición que salió. Y para pintar los buffer usa la extensión
XRender.
También tenemos otros experimentos como por ejemplo Luminocity, que se
hizo muy famoso por los videos que circularon donde las ventanas se
movían como si fueran hojas con cinemática. Luminocity lo que hacía era
ser un gestor de ventanas y gestor de composición donde la gestión de
composición la hacía con OpenGL. Pero también hay que decir que
Luminocity no es más que un proof-of-concept.
También ha existido glxcompmgr que fue el primer gestor de composición
de Xgl.

Y lo importante... jejeje, ayer o antes de ayer no lo sé (del 8-10 ha
sido el XDevConf, osea la conferencia de desarrolladores de las X), el
desarrollador de Xgl ha presentado un nuevo proyecto que se llama
Compiz, el cual es gestor de ventanas y gestor de composición y dentro
del pack trae todos los efectos de los cubos que hemos visto.
Entonces si lo que me preguntas es como lo harán los gestores de
ventanas que existen ahora... pues te diré que no lo sé. Por ahora no
hay problema en usar por un lado el gestor de ventanas y por otro lado
el gestor de composición, pero con el anunció de Compiz el desarrollador
de Xgl ha dicho que se deberían juntar ambos gestores porque sino es
complicado hacer que ambos gestores se pongan de acuerdo.

> Esta previsto integrar Xgl dentro de las X? Tiene sentido eso que acabo
> de preguntar?

Es una pregunta a la que no se responder porque no se a que te refieres
xDDDD.

Xgl es un servidor de las X que funciona encima de una implementación de
OpenGL. Es decir, no hay un driver de las X como hasta ahora, lo que
necesitarás es una librería OpenGL acelerada. La pregunta del millón
jejejeje, es de donde vas a una implementación de OpenGL sin las X... y
es por eso que la actual versión de el Xgl que se llama Xglx es en
realidad un servidor de las X que corre como aplicación OpenGL sobre
otro servidor de las X normal. Osea que las demos usan 2 servidores de
las X, el uno encima del otro.
Aunque esto en el futuro no va a ser así, lo que ocurre es que para
desarrollar Xgl es la forma de hacerlo porque la versión del opengl
libre llamado mesa3d que funciona sin las X que se llama mesa3d solo
esta aún un poco verde. Este servidor de Xgl que correrá sin las X se
llamará Xegl, donde egl significa OpenGL-es que es otra spec de opengl
especial para móviles. Aparte también aparecerán con el tiempo Xwgl
(sobre el OpenGL de windows) y Xagl (sobre el OpenGL de apple).

Y si la pregunta es la relación entre Xgl y Xorg... entonces he de decir
que la pregunta es mucho más complicada.
Xgl existe en dos repositorios distintos en freedesktop (ojo de que cvs
os bajaís el código).

Por un lado tenemos el xserver, que es la rama experimental del servidor
de las X y cuyo código es más simple y cuyo modelo de drivers esta
basado en kdrive (aka Xtiny, que igual os suena a los que uséis PDAs). Y
en este proyecto no hay drivers cargables ni na... cada drivers en un
binario distinto con todo el servidor de las X, y de esta manera te
encuentras servidores nombrados como : Xati, Xvesa, Xegl, Xmga... que
son todo el servidor de las X y que suelen ocupar muy poco.
Por ejemplo tenemos un servidor de las X llamado Xephyr que corre encima
de otra sesión de las X y que esta pensado para testear apps para PDA en
nuestro escritorio, y que además es mucho mejor que Xnest porque te
permite tener un servidor de las X dentro de otra sesión de las X con
distinta profundidad de color y con Composite... y ocupa poco, muy
poco :

$ du -hs /usr/bin/Xephyr
797K    /usr/bin/Xephyr

$ dpkg -L xserver-xephyr | grep -v /usr/share/doc | while read f; do
[ -f "$f" ] && echo "$f"; done;
/usr/bin/Xephyr

Después esta Xorg, xorg se supone que es la reference implementation, es
decir, no solo es un proyecto que sucede a XFree, es algo más
importante. 
Xorg se supone que es servidor de X.org osea el organismo que gestiona
el desarrollo de las X. Lo que ocurre es que el proyecto Xorg surgió
porque el organismo X.org que gestiona el desarrollo de las X decidió
reorganizarse y liberarse y permitir que el desarrollo de las X sea
liderado por una comunidad de software libre. Con lo cual cuando sale
una versión nueva de las X, no solo es una nueva release/versión de un
servidor de las X, es una nueva release del standard de las X, y si
existe una implementación privativa de las X (que ya empiezan a
escasear) deberían basarse en Xorg y permanecer compatible con el.

Volviendo a Xgl, pues si... Xgl existe en ambos repositorios, jejeje,
aunque se supone que el Xgl que existe en Xorg es el oficial. Sobre como
configurar Xgl... Xgl no usa ficheros de configuración porque no usa la
arquitectura de drivers de Xorg/XFree, osea como el xserver, con lo cual
tendrás dos binarios si compilas Xgl, el Xglx para funcionar dentro de
otro servidor de las X que te de el OpenGL y Xegl que será por si
quieres usarlo sobre {mesa3d solo,dri-egl}.

Respecto a esto último, jejejeje, habrá que ver que ocurre con NVidia y
ATI y los drivers privativos, porque por ahora el Xegl solo funciona
encima de las radeon R200 con dri-egl :)

> Cairo por ejemplo iria sobre Xgl?

Cairo es una librería 2d, lo que ocurre es que cairo ha sido un proyecto
clave, al principio cairo se llama Xr y como se puede intuir jejeje, se
asemeja a XRender, es decir, nació como proyecto de los desarrolladores
entre los cuales uno era el arquitecto de XRender para crear una
librería de gráficos vectoriales usando a saco el nuevo modelo de dibujo
de las X que se llama XRender.
Hasta ahora existían más librerías 2d, pero todas las librerías 2d
hacían el renderizado por software ninguna usaba XRender para intentar
ser acelerada. Cairo ha resultado muy interesante para testear XRender y
de hecho existe una app que se llama cairogears que se usa como
benchmark de XRender.
Lo que supuso el principio de Xgl fue cuando dentro del proyecto Cairo
aparecieron dos desarrolladores que estaban haciendo su tesis doctoral
sobre una implementación del modelo de dibujo de XRender sobre OpenGL y
así ganar un rendimiento bestial y usar a saco las GPUs, a este
desarrollo se le llamó Glitz.

En el futuro la aceleración de gráficos 2d se va a poder hacer de dos
maneras :
- o bien usando Cairo de manera normal, es decir el backend de Cairo que
hace llamadas XRender al servidor de las X y estas llamadas XRender son
aceleradas (en el caso de Xgl, Xgl usa Glitz para transformar XRender a
OpenGL)
- o usando Cairo con Glitz donde el resultado sería una
superficie/textura OpenGL.

De manera que como se puede ver de una manera directa o indirecta se
espera que Glitz acabe acelerando el tema.

De todas maneras el tema no queda aquí, yo no tengo claro que va a
suceder, por ahora Cairo no va muy bien y los desarrolladores dicen que
es porque falta de optimización... yo ya empiezo a dudarlo y empiezo a
creer que tiene que ver con que los algoritmos que eligieron sean
super-mega-presisos y super-mega-numéricamente estables en vez de elegir
otros más simples y más rápidos.
Por lo que si alguien quiere fama y gloria, le sugiero que implemente un
backend de cairo usando otra librería 2d como puede ser agg (anti-grain
geometry) o libart.

> Ey, si lo haces hazte un jautu o algo tio.

Un how-to de? de compilar Xgl? Bufff eso se quedaría desfasado en 2 días
xDDD, tu fíjate en estos momentos tienes que pillarte el código de una
branch del cvs... osea que para dentro de no mucho la branch ya no
valdrá y habrá que usar el trunk o algo peor xDDDD, como hace 1 mes, que
el código "liberado" salió en un tarball que ni los desarrolladores
conseguían compilar xDDDD.

Bueno ya siento que me haya quedado un poco espeso el email... es que
llevo dos días un poco espeso y a pesar de que lo reescribo (el email)
me vuelve a quedar espeso xDDDD, y tampoco voy a estar 3 días
reescribiéndolo xDDD.

Un saludete!!

[G]JonAn.