Zack Rusin, desarrollador de Qt y KDE, realiza una comparativa de rendimiento de renderizado de polígonos entre las ramas de desarrollo de Qt(4.3) y Cairo(Git). El renderizado de polígonos suele ser la operación de dibujo más costosa realizada por gráficos vectoriales. ¿El resultado? Qt es de 2 a 10 veces más rápido que Cairo según qué test!
"Objectivity aside, Qt rocks. It really does. And if you're using Qt and not using Qt's rendering architecture, everyone should point at you and make fun of you for not having complete and utter trust in me, as the only true graphics ninja and the team of Trolltech's Samurai Graphics Assassins."
Como en la mayoría de las ocasiones, no es oro todo lo que reluce, y la situación no pinta blanco sobre negro.
Amanithvg es una librería de renderizado de gráficos vectoriales que aparece en una de las pruebas. Pues bien, un desarrollador de la citada librería comenta que le parece una obviedad que el método de teselación (opción escogida por Cairo y Amanithvg) es más lento que el uso de stencil-buffer (Qt).
Sin embargo, en muchas ocasiones se usan ampliamente iconos svg, fuentes vectoriales, mapas gis y otros elementos gráficos que no necesitan ser re-teselados en cada "frame". En esos casos que son muy frecuentes, el enfoque de la fuerza bruta usado en la técnica de stencil-buffer es más lento que en el de la teselación.
#2 Olvidas el pequeño detalle de que el trabajo, de manejar stencil-buffer va a la GPU, y por eso cuando se usa opengl se dispara la velocidad. Porque, oh, la "pila opengl" (libreria+driver+gpu) es una bestia de comer poligonos.
Todos los benchmaks sintenticos hay que cogerlos con pinzas, pero este se ve claramente el resultado. Y deja bien claro que es lo que mide, pintar poligonos, no escenas complejas, no degradados complejos, no interación. Solo dibujar poligonos, y en esto se ve que hoy Qt4 gana claramente. Ahora solo falta que salga otro benchamark que simule un trabajo mas real para refinar las conclusiones.
Soy Gnomero pero me muero de ganas probrar el KDE 4, espero que no me decepcionen y me den un motivo para abandonar el FF por el Koqueror que renderizando html le da patadas hasta al Opera.
Pues entonces que alguien me explique por que las imágenes se redimensionan mucho más rápido en el visor de imágenes de Gnome que en el de KDE... bueno, ya me respondo yo solo: porque Gnome usa la librería imlib, del proyecto enlightenment.
A parte de eso, los gráficos vectoriales si que los maneja mejor KDE que Gnome. Sin ánimo de trollear, eh? que yo también soy un KDEero.
#4: yo tengo KDE 4 - 3.99, versión desarrollo - funcionando, aquí puedes ver una captura:
(dentro de la ventana Xephyr). Por ahora nada del otro mundo, de hecho se ve bastante feo porque lo tengo sin antialiasing debido a que no tengo configuradas bien las fuentes de texto. No obstante ya está portada la base a Qt4, y dentro de ~6 meses tendremos todo un señor KDE 4
Comentarios
"Objectivity aside, Qt rocks. It really does. And if you're using Qt and not using Qt's rendering architecture, everyone should point at you and make fun of you for not having complete and utter trust in me, as the only true graphics ninja and the team of Trolltech's Samurai Graphics Assassins."
Sólo por esto ya se merece un meneo
Como en la mayoría de las ocasiones, no es oro todo lo que reluce, y la situación no pinta blanco sobre negro.
Amanithvg es una librería de renderizado de gráficos vectoriales que aparece en una de las pruebas. Pues bien, un desarrollador de la citada librería comenta que le parece una obviedad que el método de teselación (opción escogida por Cairo y Amanithvg) es más lento que el uso de stencil-buffer (Qt).
Sin embargo, en muchas ocasiones se usan ampliamente iconos svg, fuentes vectoriales, mapas gis y otros elementos gráficos que no necesitan ser re-teselados en cada "frame". En esos casos que son muy frecuentes, el enfoque de la fuerza bruta usado en la técnica de stencil-buffer es más lento que en el de la teselación.
#2 Olvidas el pequeño detalle de que el trabajo, de manejar stencil-buffer va a la GPU, y por eso cuando se usa opengl se dispara la velocidad. Porque, oh, la "pila opengl" (libreria+driver+gpu) es una bestia de comer poligonos.
Todos los benchmaks sintenticos hay que cogerlos con pinzas, pero este se ve claramente el resultado. Y deja bien claro que es lo que mide, pintar poligonos, no escenas complejas, no degradados complejos, no interación. Solo dibujar poligonos, y en esto se ve que hoy Qt4 gana claramente. Ahora solo falta que salga otro benchamark que simule un trabajo mas real para refinar las conclusiones.
Nuevo post del autor con preguntas frecuentes sobre el benchmark, en particular explicando que no hay tanta diferencia a pesar de los resultados: http://zrusin.blogspot.com/2006/10/disappointing.html
#5 root@paloalto:~?!!!!!
molaría más bill@microsoft.com:~
Zack es bueno y seguro que vemos todos sus hacks en KDE4. Sólo hay que ver algunas de sus entradas como botón de muestra al futuro de KDE.
#5 es un KDE3 aparentemente, a ver cuando vemos cosas bonitas. Por cierto... buen navegador usas tu eh
Soy Gnomero pero me muero de ganas probrar el KDE 4, espero que no me decepcionen y me den un motivo para abandonar el FF por el Koqueror que renderizando html le da patadas hasta al Opera.
Me muero de ganas por tener KDE 4 funcionando
Pues entonces que alguien me explique por que las imágenes se redimensionan mucho más rápido en el visor de imágenes de Gnome que en el de KDE... bueno, ya me respondo yo solo: porque Gnome usa la librería imlib, del proyecto enlightenment.
A parte de eso, los gráficos vectoriales si que los maneja mejor KDE que Gnome. Sin ánimo de trollear, eh? que yo también soy un KDEero.
#4: yo tengo KDE 4 - 3.99, versión desarrollo - funcionando, aquí puedes ver una captura:
(dentro de la ventana Xephyr). Por ahora nada del otro mundo, de hecho se ve bastante feo porque lo tengo sin antialiasing debido a que no tengo configuradas bien las fuentes de texto. No obstante ya está portada la base a Qt4, y dentro de ~6 meses tendremos todo un señor KDE 4