El procesador prácticamente no hace nada, todo tira de tarjeta gráfica, así que, seguro que interfiere menos que un antivirus o un firewall.A mí me casca un render por esa tontería y me cago en la madre que parió al programado, r.
Hombre, es para que se aprecie la potencia.Por cierto, para que quieres ver un video encima de otro, no lo pillo.
A pues es verdad, pero entonces para los que hacemos videojuegos, no nos vale, no me hagas caso si está chulo. Saludos.El procesador prácticamente no hace nada, todo tira de tarjeta gráfica, así que, seguro que interfiere menos que un antivirus o un firewall.
Tenemos que hablar más Caronte.A ver, hay un detalle que todos pasáis por alto supongo que, por desconocimiento, muchos de esos efectos tan bonitos, no solo sirven para hacerlo más atractivo, si no que ayudan a no cansar tanto la vista. Al igual que un juego que corre a 20 frames por segundo nos cansa más la vista que uno que corre a 60 fps, es mucho más relajado que un menú aparezca con un fade o se despliegue como si fuese real. La tendencia actual es hacer las cosas lo más reales posible en todo y los interfaz no son una excepción.
¿Tenéis idea de lo que cansa la vista, por ejemplo, mover la página del navegador con la rueda del ratón?
Hacer una prueba:
Mover la rueda a grandes pasadas hasta llegar al final de la página, podréis notar como al llegar al final y hacer el mismo movimiento, nuestros ojos dan un salto porque intentan encontrar la imagen de la página más arriba como en las otras pasadas, pero como hemos llegado al final, la página no se mueve creando un malestar momentáneo.
Al igual que en animación tenemos que hacer el ease-in y ease-out para hacer movimientos reales, lo mismo pasa al mover una ventana del interfaz, y ese es uno de los motivos de que las ventanas el? Sticas (sin pasarse) sean mejores que las estíticas.



Últimamente se está dando un debate entre dos tecnologías relacionadas con el entorno gráfico de Linux: XGL (x-to-OpenGl), mantenido por Suse/Novell y aiglx (accelerated indirect gl-x), mantenido por Redhat. El primero se basa en la reescritura del xserver, mientras que el segundo plantea cambios menos traumáticos.Al fin y al cabo XGL no es más que una versión del servidor de las x que en vez de correr encima de unos drivers específicos, corre encima de un Api para gráficos que es OpenGL que además se acelera por medio de otros drivers.
Por lo tanto XGL no es más que una cuestión de diseño que aporta otras ventajas aparte del rendimiento.
Para obtener un buen rendimiento en las por lo que había que lograr era:
1º mejorar las operación de dibujo de las x.
Esto ya está hecho, el resultado es xrender. Las operación de dibujo originales se hicierón corriendo cuando se diseñarón las primeras versiones del protocolo con la idea de fueran extendidas posteriormente, pero el tiempo paso, y esa extensión ha llegado hace más bien poco.
2º hacer que las aplicaciones de cliente y los tolkits hagan buen uso del modelo de dibujo de las x.
En la página de Keith Packard, el arquitecto de xrender se puede encontrar un artículo muy interesante sobre un estudio que se hizo sobre el tipo de operación que hacías las distintas aplicaciones y tolkits, la conclusión fue que el degradamiento del rendimiento de las aplicaciones no era únicamente por las x en si mismas y si no que también era porque los tolkits no estaban nada optimizados y hacían muchas operación que consumían enormes proboolean de recursos inultimente, ¿cómo hacer miles de llamadas que pintaban un píxel, cuando podías eliminarlas pasando directamente un pixmap.
Una de las razones por las que se diseño Cairo fue precisamente para facilitar la creación de aplicaciones ricas en gráficos, y también entre otras razones porque ha sido una de las pocas aplicaciones que realmente exprimían el potencial del nuevo modelo de dibujo de las x (xrender). Gracias a Cairo se ha podido testear xrender y su aceleración a conciencia.
3º mejorar la aceleración de xrender.
Una de las primeras cosas que se han logrado es descubrir la pésima aceleración que se lograba con el modelo de drivers de las x (el xa, xfree acceleration architecture), de hecho, era tan ineficiente que anular la aceleración y hacerlo por software aceleraba el rendimiento [1].
En la última versión de las x tenemos un nuevo modelo de driver llamado exa que pretende solucionar parcialmente el problema de xa. La idea es, crear una nueva capa de aceleración que incorpora un buen diseño y un buen número de optimizaciones y después hacer las llamadas driver de toda la vida (xa). Lo que se consigue con esto es no tener que rescribir todo el modelo de drivers y todos los drivers.
Por otro lado, que ha sido una revolución ha sido glitz. Glitz es una librería que implementa el modelo de dibujo de xrender sobre OpenGL demostrando que no solo es factible sino que además se logra un excelente rendimiento. Por lo tanto, la aceleración de xrender de XGL se consigue por medio de glitz que se incorpora dentro de XGL. Eso también quiere decir que no será necesario usar glitz con las aplicaciones de escritorio que corran sobre las x, porque estas usaran Cairo, Cairo hará las operación por medio de xrender, y xrender será acelerado y convertido a OpenGL dentro del XGL por medio de glitz.
Ahora las ventajas de XGL frente a las x con otro framework de aceleración de xrender:
1º XGL corre sobre OpenGL con lo cual el servidor de las x se podrá portar fácilmente a cualquier implemetación de OpenGL.
2º se simplifica el modelo de drivers. Nos olvidamos de un driver 2d y otro 3d para pasar a un único driver 3d, también siguiendo la línea de evolución de las tarjetas gráficas que las más modernas han dejado de tener una parte 2d y una parte 3d para terminar haciendo todas las operación 2d y 3d dentro un mismo procesador programable (la GPU).
3º el servidor de las x pasa a convertirse en un programa no privilegiado. Hasta ahora las x necesitaban ejecutarse como suid para gestionar el hardware directamente sin necesidad del kernel. Ahora los drivers OpenGL que deberán implementar un modelo de seguridad son los únicos que gestionaran el hardware. El modelo de seguridad se hará mediante el componente que reside en el núcleo, es decir el direct rendering manager (en caso de DRI).
[url]http://www.osnews.com/story.php?News_id=13850[/url].The cooperación between the XGL and aiglx projects todo bring better interfaz for the Linux desktop continúes as David reveman (Novell) of XGL has agred todo adopt Many changes from the aiglx Project sent in by kristian hogsberg (Red Hat).
[url]http://lists, fredesktop.org/archives/Xorg/2006-february/013306.html[/url].Ive ben getting a lot of mail from people asking me about my thoughts.
On aiglx, the GL compositing work being done on metacity and Nvidias.
Xdevconf paper. Instead of replying todo everyone individually, y though.
Id send a mail todo the Xorg list.
Aiglx [1]. It great that we finally have accelerated indirect glx.
Working in the xfre86 ddx, something that we should have had Many years.
Ago. And with texture-from-pixmap support it should work well with.
Compiz, y like that. the DRI driver requirements for XGL and aiglx are.
Very similar so both XGL and aiglx Will benefit from DRI driver work.
Being done for one of them.
Nvidia paper [2] on why they dont think x on OpenGL is the best way.
To go is not a huge sorpresa todo me. XGL Will work equally god across.
Drivers, without requiring high-quality x drivers from all the vendors.
In that bien XGL levels the playing field for hardware vendors. Nvidia.
Already has god drivers with some functionality that it Will take a.
While before XGL can support. Compiz Will work fine on Xorg with the.
Nvidia driver once they reléase a versión with the texture-from-pixmap.
Support XGL already got. But Nvidia isnt the only hardware vendor on.
The market, and we want the x desktop experience todo be as rich as.
Posible for everyone.
An important goal with x on OpenGL is todo make it easier for x todo kep up.
With the advances in graphics hardware. eliminating the custom 2d.
Acceleration code Will reduce the development burden and make this.
Easier. this can probably be achieved th rouge aiglx as well, y know that.
The people working on aiglx have discussed putting some of the.
Acceleration code i have in XGL inside Xorg with aiglx and that would be.
A step in that direction. However, y strongly believe that going all the.
Way todo an x server completely on top of the OpenGL Api is the best.
Solution in the long run.
I think the arguments made by Nvidia todo why x on OpenGL would be worse.
Than the current driver architecture can be debated on until forever. I.
Thinque it all boils down todo if we want put some more efort todo it and.
Take the big scary step todo something new or if we want todo stick todo the.
Old well known. Not todo surprising, we have people who are in favor of.
Both and well likely have development being done on both, which i dont.
Thinque is that bad After all.
So far i havent heard a single argument for why x on OpenGL is a bad.
Idea other than that it a big step and a lot of work Will have todo be.
Done. If that would estop me from working on XGL, y wouldnt have started.
Working on it in the first place.
Except the fact that it might Slow down development of XGL a Little, i.
Thinque that both aiglx and Nvidia plan todo support texture-from-pixmap.
Are really god things that Will make the x desktop better in the.
Near future.
Im a Little bit concerned about the work being done on GL compositing.
In metacity. During the first couple of months when i was experimenting.
With GL compositing on XGL i had similar plans but After a few months i.
Realized that starting from scratch and trying todo reuse as much code as.
Posible was the best idea. Others might be able todo do a better job than.
Me on figuring out how todo extend metacity but i think it todo early todo.
Tell as the people working on metacity that i talked todo at xdevconf.
Didnt sem todo be aware of issues im solving by not using an ordinary.
Window manager like metacity for compositing. An important reason todo why.
I favor Compiz over metacity is that it works with other desktop.
Environments than Gnome. I definitely dont want all these effects that.
People are starting todo write todo only be usable on one desktop.
I dont like a Compiz/metacity Split but im not sure what we can do.
Here. Ill continúe todo reuse metacity code in Compiz as plugins and ill.
Have a look at libcm asap and consider the possibility of integrating it.
With Compiz somehow.
There sems todo be a lot of people confused about this, so todo clarify.
Things, y a los like todo respond todo this paragraph from the Fedora aiglx.
Page:
Weve ben working on the aiglx code for a some time with the.
Community, which is in direct contrast with the bien that XGL was.
Developed. XGL spent the last few months of its development behind.
Closed dors and was dropped on the community as a finished solution.
Unfortunately, it wasnt per reviewed during its development process.
And its architecture doesnt sit well with a lot of people.
Ive ben develooping XGL in the open since noviembre 2004. Only the last.
Few months have ben behind closed dors. I can agre that this wasnt.
The best thing but no architectural changes have ben made during this.
Period, just a lot of hard work implementing missing functionality.
Tracking down and fixing bugs in XGL and various other places in the x.
Server tre. We didnt drop a finished solution, we dropped a much.
Improved versión, that all.
At the time the decisión was made todo estop push things into cvs for a.
While, no one except me was really contributing todo the Project and the.
Testing and bug reports we got from the community didnt give us much.
If we had todo make architectural changes or if the interest in.
Contributing todo the Project got bigger, the idea was always todo open.
Development again.
David.
Vaya, claro que sí, predicador.¿A alguien más le interesa esto o estoy predicando en el desierto?
En Suse (bueno, ahora open Suse) también funciona. Si la debían no te convenció deberías probar la Suse. Además, Suse es de Novell (el padre de la criatura en cuestión.Buenas a todos definitivamente esto me anima a volver a instalar Linux después de mi último desastre informático, mi duda es, esta versión de XGL se puede instalar con cualquier distribución, la última que instalé era una slackware, ahora quería probar una debían a ver qué tal va, aparte de con la Ubuntu que tiene viriathus, sabéis si tira con alguna otra distribución.
El problema son las Ati en general con Linux. Bueno, no de Ati sino de los drivers que rulan por ahí, además, hay un par de modelos de Ati que son incompatibles con el XGL. Mira en la página web porque además encontraras información para instalarlo sobre Ati. Un abrazo.Posdata: confieso que, aunque instalé varias distribuciones de Linux mis conocimientos del sistema operativo, son bastante limitados, como añadido tengo una Ati y estaba mirando en la página de XGL que casi todo va bien con las Nvidia.
La verdad es que viendo las ventajas que implica tener un escritorio con aceleración 3d, tengo algo más de respeto por Windows Vista. Quisiera preguntar a los que estén más informados en cuanto a juegos y DirectX, ¿en qué orden colocaríais estos tres elementos - Fabricantes de juegos, fabricantes de tarjetas gráficas, desarrolladores de DirectX- A la hora de determinar que va a ser lo siguiente que se implemente en las tarjetas gráficas? O sea, ¿quién marca el ritmo? A lo que voy es que tengo la sensación de que es Microsoft con su DirectX el que determina este ritmo, y que esto puede suponer un freno al desarrollo de OpenGL. Para mí que DirectX muestra una Api y a partir de ahí se desarrolla el hardware gráfico, mientras que en Linux es al revés: los fabricantes muestran una Api y en luego los programadores dan soporte sobre las nuevas funcionalidades. Y claro, no es que estén por la labor Ati y Nvidia de facilitar las cosas.Sigo opinando que el Gates se guarda el as en la manga, ya veremos que pasa.