16 meneos
151 clics

Ubuntu 12.10 ya no redirige las ventanas en pantalla completa para un mayor rendimiento en juegos

Para mejorar el rendimiento de los juegos OpenGL, Ubuntu 12.10 ha recibido esta mañana una actualización con la que Compiz ya no redirige las ventanas por defecto. Usuarios informan de que con este cambio se obtienen mejoras de un 50% o más. Tener ventanas dibujándose directamente en la pantalla en vez de en un buffer secundario logra mejoras de rendimiento palpables para muchos juegos OpenGL.
etiquetas: ubuntu 12.10, unredirected mode, compiz, juegos, quantal quetzal
usuarios: 14   anónimos: 2   negativos: 0  
56comentarios emnm karma: 117
  1. #1   Elementary OS con su fork de Gnome Shell sigue siendo mucho más rapido que Unity y mucho más simple.
    votos: 2    karma: 28
  2. #2   #1 Más les vale espabilar a Ubuntu en rendimiento de juegos que steam quiere entrar de lleno a Linux.
    votos: 0    karma: 10
  3. #3   juegos de linux?... el tetris?
    votos: 0    karma: 6
  4. #4   #3 El NetHack :-P . Bueno miento, ese juego creo que está en Windows así que no vale :p.

    Na, a ver si Valve se decide a portar la saga de Half Life.
    votos: 0    karma: 11
  5. #5   #1 #2 y no podría instalar yo Steam en ese en lugar Ubuntu? Es que me va fatal y no tengo ni jodida idea por qué :-/

    </preguntabytheface>
    votos: 0    karma: 8
     *   Lobazo Lobazo
  6. #6   #4 y que no han portado ya l4d 2?
    votos: 0    karma: 10
  7. #7   #5 Sí. Elementary OS usa los repos de Ubuntu 12.04 para los demás programas.
    votos: 1    karma: 19
  8. #8   #7 Ya lo tengo descargado :-D
    votos: 0    karma: 8
  9. #9   #8 Suerte. Está en beta pero si actualizas cada día no deberías tener problema.
    votos: 1    karma: 19
  10. #10   #9 Muchas gracias, ha sido todo un descubrimiento, es una distro preciosa :-O
    votos: 0    karma: 8
  11. #11   #1
    A la que quieras composición no hay ningún gestor de ventanas que haga unredirection en una ventana fullscreen por defecto, incluyendo kwin.
    votos: 0    karma: 7
  12. #12   #1 Barriendo para casa, puedes probar GameD (www.rastersoft.com/programas/gamed_es.html), un daemon que escribí para dar máxima prioridad a las X y al gestor de ventanas, y mejorar el rendimiento de juegos OpenGL mientras no implementas esto mismo en Elementary.
    votos: 0    karma: 9
  13. #13   #12 Elementary OS tiene un fork de mutter(Gala) el cual tiene un soporte mejorado de juegos OpenGL.

    Te lo digo por experiencia. Jugando al SSAM2 sin ningún bajon de FPS, superando a XFWM4.

    PD: Sin vala:

    renice -10 -p `pgrep X`
    votos: 0    karma: 11
     *   Ander_ Ander_
  14. #14   #13
    La magia negra no existe y suele ser ampliamente «placébica».
    votos: 0    karma: 7
  15. #15   #14

    Han parcheado el gestor de ventanas de G3 para acelerarlo, en serio, pruébalo.

    He usado el G3 de Fedora con los drivers oficiales de Nvidia e iba a veces algo tieso. Y eso que Fedora optimizan mucho para el escritorio y Gnome3.

    Con Gala noto bastante más fluidez, y sobre todo, Serious Sam2 y Steam tiran sin freir el portátil.

    #16 Sí y no. Kwin y E17 llaman ambos igualmente a X y créme que E17 tira mucho más rapido que Kwin efectos incluídos.
    votos: 0    karma: 11
     *   Ander_ Ander_
  16. #16   #15
    Mientras no sea una reimplementación de OpenGL y el servidor X no sirve para nada más allá de lo que permiten tanto Compiz como KWin opcionalmente y que ahora Ubuntu activa por defecto.

    #15
    El que los efectos de KWin sean menos fluidos (por la mayor vistosidad/complejidad) no influye en nada en el rendimiento de los videojuegos, más aún si tenemos en cuenta el uso de modo sin redirigir.
    votos: 0    karma: 7
     *   Filiprino Filiprino
  17. #17   #16 Depende como implementes el gestor de ventanas. Hasta entre Openbox y Fluxbox puede haber diferencias de velocidad.

    Te lo dice un usuario de Linux desde Debian Woody que ha probado cientos de gestores.

    Prueba Kwin sin efectos y E17 sin cargar el escritorio, ambos desde .xinitrc junto con urxvt y lanza ahí el juego.

    #.xinitrc
    urxvt &
    exec kwin
    #exec e17 (o como se llame el gestor de Enlightenment)

    #18 Y Xterm, konsole, urxvt ,donde irónicamente, hamijo, Xterm es la terminal más lenta de todas.
    votos: 0    karma: 11
     *   Ander_ Ander_
  18. #18   #17
    Por diferencias de velocidad las hay incluso entre GNOME Terminal y Terminator, o Vim y Vi.

    No lo voy a probar porque sé que no sirve para nada. Si me presentas medidas de rendimiento tomadas con un método fiable sobre imágenes independientes de un entorno limpio, entonces ya podrás comenzar a hablar.

    Exacto, y las diferencias son tan estadísticamente significantes que realmente sí, uno es más rápido que el otro.
    votos: 1    karma: 18
     *   Filiprino Filiprino
  19. #19   #13 Uso ElementaryOS, y precisamente lo escribí porque lo necesitaba. El juego "Limbo" me iba a tirones (unos 7 FPS) y con un retardo brutal entre pulsación y acción (casi un segundo; completamente injugable). En cuanto subí la prioridad de Gala y X, tiró perfectamente. Por eso lo automaticé con GameD.
    votos: 0    karma: 9
     *   rastersoft rastersoft
  20. #20   Y a los que dicen "placebo": sí hay un motivo para que se produzca este efecto, y para que un aumento de prioridad en el gestor de ventanas y las X lo resuelva (o, al menos, lo suavice). Los gestores por composición hacen que las aplicaciones no pinten en pantalla directamente, sino en una zona de memoria aparte, y luego es el gestor de ventanas el que copia esas zonas en pantalla, en el orden correcto. Así, cuando una aplicación cambia algo, se produce un evento para las XWindows que avisa de que esa zona se ha modificado. Las X lo retransmite al gestor de ventanas, que da la orden a las X de pintar ese cacho en pantalla en el sitio adecuado.

    El problema es que las X y el gestor de ventanas son procesos diferentes del juego, lo que significa que para que las X respondan a ese evento hace falta esperar a que linux decida robarle el procesador al juego y se lo ceda a ellas. Y lo mismo para que el gestor pueda responder al evento que le envia las X. Con un juego, que actualiza la pantalla varias decenas de veces por segundo, el resultado es que las X y el gestor se llaman muchas veces por segundo, lo que hace que linux le baje la prioridad. Y en ese caso, lo que ocurre es que tarda más en decidir quitarle la CPU a otros procesos (incluido el juego) para cedersela a ellos, con lo que fácilmente el juego puede trazar varios frames, y sólo entonces la CPU cambiar a las X para que los pinte (obviamente sólo el último).

    Subiendo la prioridad de las X y el gestor de ventanas conseguimos que, tan pronto el juego emita el evento de que hay una pantalla lista para mostrarse, linux le quite la CPU y se la ceda a las X y al gestor, con lo que la pantalla se actualiza casi al instante (que es justo lo que queremos).

    Y lo mismo, pero al revés, con las pulsaciones de teclas y ratón: son eventos leidos por las X, que tienen que ir hasta el juego, pero que sólo llegarán cuando las X consigan algo de CPU.
    votos: 0    karma: 9
  21. #21   #19 ¿Jupiter o la beta? Ah,vale, Gala. Pues yo repito que con la Nvidia me iba más lento con Unity que con Gala.

    #20
    ¿Quieres aún más velocidad? Lanza el juego en su propio servidor X.
    votos: 0    karma: 12
     *   Ander_ Ander_
  22. #22   #20
    Felicidades, pero eso no explica que vaya a haber diferencias de velocidad entre gestores de ventanas porque el proceso es exactamente el mismo en el caso de las ventanas a pantalla completa para todo gestor de ventanas.

    La única forma de obtener un rendimiento razonablemente extra es no utilizar gestores de ventanas y ejecutar el juego directamente sobre el servidor X. Aún así la diferencia es mínima ya que el límite principal lo impone el propio protocolo X (tal y como tú explicas) y la implementación OpenGL que éste requiere.
    votos: 0    karma: 7
  23. #23   #21
    Pues yo repito que con la Nvidia me iba más lento con Unity que con Gala.
    Puedes repetir todo lo que quieras, sólo demuestras ignorancia, y directamente que no te lees las entradillas de los meneos en los que escribes.

    Unity no es un gestor de ventanas, el gestor de ventanas es Compiz y el escritorio es GNOME 3. Unity es sólo un plugin para Compiz y GNOME 3.
    votos: 0    karma: 7
  24. #24   #23 Vale, Unity/Compiz :p.

    Y yo te repito que Gala ha sido parcheado para permitir lo mismo que activan ahora compiz por defecto, amén de otras optimizaciones. Pero aún así sigue siendo más rapido Gala dibujando que Compiz.

    Y el escritorio con Unity no es Gnome3 ya que quiere Gnome Shell para serlo. Si quieres Gnome3, vete a Fedora, por que Unity+Compiz no es G3.

    ""Puedes repetir todo lo que quieras, sólo demuestras ignorancia, y directamente que no te lees las entradillas de los meneos en los que escribes."

    Llevo con Linux desde Debian Woody y probé compiz cuando necesitaba XGL. Lo dudo. Espero que no hayas pasado por la tortura de tener que usar mknod para crear dispositivos a mano cuando no había ni devfs ni udev.

    Te digo que el entorno de Elementary va más rapido que en G3 tanto en fluidez de uso como en los juegos.

    Y no uso ahora Elementary precisamente, tengo Debian Sid con DWM.
    votos: 0    karma: 12
     *   Ander_ Ander_
  25. #25   #24
    Unity es GNOME 3 sin Gnome Shell que incluye a Mutter.

    Llevo con Linux desde Debian Woody y probé compiz cuando necesitaba XGL. Lo dudo. Espero que no hayas pasado por la tortura de tener que usar mknod para crear dispositivos a mano cuando no había ni devfs ni udev.
    He pasado otras torturas. Llevar varios años usando GNU/Linux no significa que no desconozcas las verdaderas fuentes de ineficiencia y cómo obtener mejoras reales de rendimiento.
    No hace falta una dilatada experiencia para saber que "otras optimizaciones" son prácticamente inútiles y aportan muy poco. Compiz no ha necesitado ser parcheado, lleva soportando esta funcionalidad desde hace mucho sólo que ahora lo tienen activado por defecto.

    Te digo que el entorno de Elementary va más rapido que en G3 tanto en fluidez de uso como en los juegos.
    Y yo te digo que eso es puro placebo de diferencias mínimas no significativas, como las próximas modificaciones a Compiz para que envíe menos eventos X.

    Y no uso ahora Elementary precisamente, tengo Debian Sid con DWM.
    Muy bien.


    La conclusión que hay que sacar de todo esto es que Wayland debe estar listo lo antes posible para tener un servidor más mantenible con un protocolo más idóneo a la par que los gestores de ventanas también tendrían código más sencillo y eficiente.
    votos: 0    karma: 7
  26. #26   #25 Wayland usa composición por defecto. Me parece que no me gustaría dedicar tiempo de mi GPU/GL para el escritorio, pudiéndolo dedicar a VDPAU o juegos como hago ahora.

    Teniendo en cuenta que Enlightenment es suficientemente rápido sin usar la gráfica para nada.

    Sobre exportar el servidor remotamente, creo que con SSH nos basta a los de Unix. En eso estoy de acuerdo.

    No es solo el tema de offscreen en Compiz. Es como hacer funcionar el gestor. Compiz sigue siendo lento. E17 sigue siendo una bala.

    Wayland podrá ser eficiente con KMS, DRM, Mesa y demás, pues Nouveau es rápido en 2D, con animaciones fluidas del todo. Pero en los drivers propietarios es lo contrario. El 2D con los drivers propietarios es un asco tanto en Linux como en Windows. Y encima no hay soporte...
    votos: 0    karma: 12
     *   Ander_ Ander_
  27. #27   #26
    Me parece que no me gustaría dedicar tiempo de mi GPU/GL para el escritorio, pudiéndolo dedicar a VDPAU o juegos como hago ahora.
    VDPAU es independiente de la GPU ya que no utiliza recursos de la GPU, emplea hardware de funcionalidad fija.
    votos: 0    karma: 7
     *   Filiprino Filiprino
  28. #28   #27 Depende de la gráfica en todo caso y si activas la composición VDPAU puede o bien no funcionar en Mplayer sacandote un cuadro negro o ralentizando los FPS.

    Tengo una NV8200M y si abro un video con Mplayer con -vo vdpau activando la composición, éste no va ni a patadas. Si va -vo gl2, curiosamente.

    En Intel no parece haber esos problemas con VAAPI.
    votos: 0    karma: 12
     *   Ander_ Ander_
  29. #29   #28
    No depende de la gráfica. VDPAU utiliza hardware de funcionalidad fija en la gráfica, le podrás dar todas las vueltas que quieras. Si no utiliza hardware de funcionalidad fija entonces estás empleando la CPU para decodificar vídeo, y a la vista de tus comentarios me parece a mí que no sabes lo que realmente es VDPAU.
    votos: 0    karma: 7
  30. #30   #29 Procesamiento de video (decodificacion de medios :p) por hardware. Pero al usar GL+VDPAU, la gráfica o bien no puede con la caña o hace conflicto.

    Te digo que tengo una NV8200m aquí y tengo todo más que probado, tanto con composite activado como sin el.

    Y te digo que va a ser jodido compaginar Wayland con juegos, VDPAU y demás, gastando recursos de la gráfica a lo tonto.

    Cojona, que tengo un portátil de varios años, vas a decirme a mi lo que es conveniente o no o lo que es o no VDPAU sabiendo que si configuro algunas cosas esto literalmente... se fríe.
    votos: 0    karma: 12
     *   Ander_ Ander_
  31. #31   #30
    Pero al usar GL+VDPAU, la gráfica o bien no puede con la caña o hace conflicto.
    Error. La gráfica no recibe caña. Es un problema de la implementación de VDPAU y del driver gráfico. Como ya he dicho y tú mismo dices, VDPAU no emplea recursos de GPU, por lo que no hay varios problemas posibles, sólo uno.

    Y te digo que va a ser jodido compaginar Wayland con juegos, VDPAU y demás, gastando recursos de la gráfica a lo tonto.
    Te recomendaría que dejases de decir tonterías.

    Cojona, que tengo un portátil de varios años, vas a decirme a mi lo que es conveniente o no o lo que es o no VDPAU sabiendo que si configuro algunas cosas esto literalmente... se fríe.
    Te recomendaría pues que alguien te instruyera en el uso de los ordenadores, porque visto lo visto y tras varios años has adquirido conocimientos erróneos.

    #32
    Que Kwin 4 es una castaña es algo que todos sabemos.

    ¿Quieres hablar de cosas relacionadas tanto con VDPAU por un lado como el rendimiento en videojuegos por el otro?

    Kwin4 junto con KDE4 es una bazofia infumable e intratable desde el punto de vista de rendimiento.
    votos: 0    karma: 7
     *   Filiprino Filiprino
  32. #32   #31 "La gráfica no recibe caña" Mis cojones no recibe caña.

    Abre el Serious Sam 3 en Kwin con composición desactivado para aplicaciones a pantalla completa, abrelo ahora sin ningún tipo de composición y comprueba las temperaturas.

    ¿Quieres que postee aquí los resultados de sensord y sensors, tanto para CPU como para GPU?

    * Kwin4 a partir de KDE4.8 es de los gestores más rapidos que hay superando a Gnome Shell de lejos incluso activando la composición. La 4.9 es bastante decente.

    Creo que hablas de KDE 4.5 y anteriores.
    votos: 0    karma: 12
     *   Ander_ Ander_
  33. #33   #31 "Te recomendaría pues que alguien te instruyera en el uso de los ordenadores, porque visto lo visto y tras varios años has adquirido conocimientos erróneos."

    Claro, hombre, claro, los estudios y la experiencia metiendo UNIX en portátiles no son nada.

    "¿Quieres hablar de cosas relacionadas tanto con VDPAU por un lado como el rendimiento en videojuegos por el otro?"

    Tienen que ver. La composición es un puto lastre, hablando resumidamente. Y van y los de Wayland lo meten por defecto. Bravo.

    La composición añade un lag y el tema de sincronizar solo puede crear una cosa: lentitud a la hora de recibir eventos del ratón y teclado en los juegos .
    votos: 0    karma: 12
     *   Ander_ Ander_
  34. #34   #33
    Claro, hombre, claro, los estudios y la experiencia metiendo UNIX en portátiles no son nada.
    En tu caso, eso parece.

    Tienen que ver. La composición es un puto lastre, hablando resumidamente.
    Si no sabes utilizar ordenadores no es mi culpa. La composición no es ningún problema, y si viene por defecto e integrada mejor.
    La composición añade un lag y el tema de sincronizar solo puede crear una cosa: lentitud a la hora de recibir eventos del ratón y teclado en los juegos .
    La sincronización sólo existe en X.org ya que es un protocolo asíncrono.
    ¿Quieres que postee aquí los resultados de sensord y sensors, tanto para CPU como para GPU?
    El problema de sensord y sensors es que suelen fallar más que una escopeta de feria en cuanto a sensores detectados y temperaturas leídas.
    Por otra parte si una tarjeta gráfica no coge altas temperaturas en un videojuego ni se ocupa al 100% es que algo está yendo mal, por muy simple que sea el videojuego, salvo que sea 2D claro. Puedes dejar tus cojones tranquilos.
    votos: 0    karma: 7
     *   Filiprino Filiprino
  35. #35   #34 Sí es un problema la composición. Quizá no para ver una peli. Unos milisegundos en juego de FPS o carreras puede significar la partida a tomar por saco, no hablemos en red.

    "There is also the idea of relaying input events only once per frame."

    Esto es lo que dicen los desarrolladores de Wayland. Pues eso. Nada más que hablar.
    votos: 0    karma: 12
     *   Ander_ Ander_
  36. #36   #35
    Esto es lo que dicen los desarrolladores de Wayland. Pues eso. Nada más que hablar.
    Ah, ¿pero es que alguna vez has hablado? Sólo has dicho cosas sin sentido, como eso mismo, que no sabes ni lo que significa ni las implicaciones que tiene.
    votos: 0    karma: 7
  37. #37   #36 Lo que tu digas, hala, voy a comer. Espero que esa aberración nunca sustituya a X.

    "Ah, ¿pero es que alguna vez has hablado? Sólo has dicho cosas sin sentido, como eso mismo, que no sabes ni lo que significa ni las implicaciones que tiene."

    Sí, seguro... anda, activa VSYNC en le juego y luego júntalo con la idea de Wayland. Luego coge un ratón de alta precisión.

    Arranca el Xonotic y el juego sí, va como la mantequilla. Lástima que recibes las cosas 20ms después de recibir un disparo en la cabeza.
    votos: 0    karma: 12
     *   Ander_ Ander_
  38. #38   #37
    Lo que tu digas, hala, voy a comer. Espero que esa aberración nunca sustituya a X.
    Espero que te siente bien la comida. Recuerda establecer un protocolo cada vez que quieras coger tu cubierto y luego hacer que interactúe con el plato enviándose mensajes constantemente entre ellos como si fuera una conexión en red.

    Sí, seguro... anda, activa VSYNC en le juego y luego júntalo con la idea de Wayland. Luego coge un ratón de alta precisión.
    No hay ningún problema en ello, como tampoco lo hay en Windows. Averigua qué es lo que se hace para construir un fotograma y qué información se emplea y en qué momento y cómo se recoge.

    Arranca el Xonotic y el juego sí, va como la mantequilla. Lástima que recibes las cosas 20ms después de recibir un disparo en la cabeza.
    Cómprate un monitor mejor o contrata una conexión a Internet mejor.
    votos: 0    karma: 7
  39. #39   #38 En eso tienes razón sobre lo de X, ya he dicho antes que con SSH nos basta a los de UNIX. No tengo nada contra Wayland si establecen la composición como opcional.

    Mi netbook ARM WM8650 no tiene soporte acelerado 2D/3D alguno y oye, al menos tira con Debian y DWM y X a 16bit( para ahorrar RAM en la máxima medida de lo posible pues usa el chipset integrado de VIA).
    Con Wayland me jodo. Y oye, CgoBan y el emu de la GameBoy me desestresan a veces.

    Sobre lo del monitor, eso pasaría al activar Wayland+Vsync+juegos GL.

    EDIT: ¿Con XCB no aligeraron todas esas llamadas que tenían que hacer?
    votos: 0    karma: 12
     *   Ander_ Ander_
  40. #40   #39
    GNU == GNU is Not UNIX. Que sea un sistema tipo UNIX no significa que sea UNIX.

    En fin, puedes seguir tu camino del placebo, espero que en cuestiones de salud no utilices la homeopatía.

    ¿Con XCB no aligeraron todas esas llamadas que tenían que hacer?
    Puedes contestarte tú mismo con cualquiera de esa ideas trasnochadas.
    votos: 0    karma: 7
  41. #41   #40 ¿Asumes que he estado solo con Linux?

    "Puedes contestarte tú mismo con cualquiera de esa ideas trasnochadas."

    Trasnochado y hortera es meter todo bajo OpenGL. Al menos DWM funciona y va como una bala.

    Y Xorg/X11 nunca ha sido GNU, sino MIT.

    "En fin, puedes seguir tu camino del placebo, espero que en cuestiones de salud no utilices la homeopatía."

    Cuando saquen Elementary stable, comparamos con Ubuntu 12.04 con la composición desactivada.

    Igual nos llevamos más de una sorpresa.
    votos: 0    karma: 12
     *   Ander_ Ander_
  42. #42   #41
    No, pero esta noticia trata de un sistema GNU.

    Además estar sólo con Linux no implica utilizar sólo un sistema GNU.

    Trasnochado y hortera es meter todo bajo OpenGL. Al menos DWM funciona y va como una bala.
    Ves como no sabes de qué hablas.

    Cuando saquen Elementary stable, comparamos con Ubuntu 12.04 con la composición desactivada.
    Igual nos llevamos más de una sorpresa.

    Si aportas algo útil por mí encantado, pero ya te adelanto que sorpresa no habrá ninguna.

    #43
    No, no estoy diciendo eso.
    votos: 0    karma: 7
     *   Filiprino Filiprino
  43. #43   #42 Estabas hablando de mí sobre sistemas Unix y que GNU no es Linux. ¿Y?

    Tmux es BSD.
    DWM es MIT.

    Esto no es de trasnochado. Lo transnochado es meter GL a todas partes por no tener ni puta idea de optimizar y soportar lenguajes lentos para que todo vaya fluido en vez de hacer las cosas bien desde el principio como E17.

    Es mi impresión. Parece que si no usan la gráfica para todo no tienen manera de mostrar un escritorio suave, oye.

    Es decir, que el scroll de aplicaciones 2D vaya fluído del todo como consigue Nouveau con KMS/DRI y E17 hasta en cualquier cacharro tipo Zipit-Z2 sin aceleración por hardware alguna.

    Y es triste, por que parece que vayamos acelerando las cosas a trompicones por fuerza bruta.
    votos: 0    karma: 12
     *   Ander_ Ander_
  44. #44   #43
    Esto no es de trasnochado. Lo transnochado es meter GL a todas partes por no tener ni puta idea de optimizar y soportar lenguajes lentos para que todo vaya fluido en vez de hacer las cosas bien desde el principio como E17.
    Lo que es un lenguaje lento es el empleado en el lenguaje de comunicación definido por el protocolo X.

    Es mi impresión. Parece que si no usan la gráfica para todo no tienen manera de mostrar un escritorio suave, oye.
    Resulta evidente que es tu impresión, de nuevo.

    Es decir, que el scroll de aplicaciones 2D vaya fluído del todo como consigue Nouveau con KMS/DRI y E17 hasta en cualquier cacharro tipo Zipit-Z2 sin aceleraciçón por hardware alguna.
    Sabemos de las bondades y no bondades del renderizado 2D a la antigua usanza. Y no, no va fluido.

    Y es triste, por que parece que vayamos acelerando las cosas a trompicones por fuerza bruta.
    Habló el que utiliza entornos minimalistas porque eso le produce la sensación de ir rápido cuando en realidad es al revés.
    votos: 0    karma: 7
  45. #45   #44 Sabemos de las bondades y no bondades del renderizado 2D a la antigua usanza. Y no, no va fluido

    E17 demuestra que si va fluido.

    Habló el que utiliza entornos minimalistas porque eso le produce la sensación de ir rápido cuando en realidad es al revés.

    Je. DWM+Dmenu+Surf+Urxvt me van como el puto rayo y el portatil se mantiene relativamente frío, y eso que no lo he abierto desde hace 4 años.
    votos: 0    karma: 12
     *   Ander_ Ander_
  46. #46   #45
    E17 demuestra que si va fluido.
    Unity demuestra que no y que la composición mediante tarjeta gráfica es una solución óptima y siempre mejor que el renderizado 2D del escritorio malgastando ciclos de una CPU de propósito general.

    Je. DWM+Dmenu+Surf+Urxvt me van como el puto rayo y el portatil se mantiene relativamente frío, y eso que no lo he abierto desde hace 4 años.
    Si no lo enciendes es normal que se mantenga frío.
    votos: 0    karma: 7
  47. #47   #44 #46 Vamos a ver, para efectos chungos claro que acelera GL más que 2D. Pero para un scroll suave, si se implementa desde el principio siendo rápido y suave como pasa con EFL y E17, la carga que tendrá un equipo haciendolos via OpenGL será mucho menor, y todo tirará como la seda en cualquier circustancia.

    E17 soporta composición en las opciones haciendo que el uso de CPU llegue a ser aún más ridículo y por lo tanto yendo a velocidad Mach 4.

    trac.enlightenment.org/e/wiki/CompositeManager

    Todos sabemos la lentitud de GTK, y al menos con GL es algo rápida, pero es que ni con Cairo tiraba fluida.
    votos: 0    karma: 12
     *   Ander_ Ander_
  48. #48   #47
    Que no. Para cualquier tipo de manipulación gráfica un chip dedicado a ello es mucho mejor y permite scrolls, movimientos de ventana y animaciones mucho más suaves con el framerate que te dé la gana.

    E17 soporta composición en las opciones haciendo que el uso de CPU llegue a ser aún más ridículo y por lo tanto yendo a velocidad Mach 4.
    Por tanto la composición es buena y no supone ningún problema.

    Todos sabemos la lentitud de GTK, y al menos con GL es algo rápida, pero es que ni con Cairo tiraba fluida.
    Las bibliotecas GTK están implementadas en C y además son una implementación muy eficiente. Se emplean en multitud de entornos de escritorio y programas con gran éxito.
    votos: 0    karma: 7
  49. #49   #48 "Las bibliotecas GTK están implementadas en C y además son una implementación muy eficiente. "

    El que son usadas en varios entornos lo sé de sobra. Eso de eficiente... espero que no te haga recordar la lentitud de GTK2 con gtkgkext y un simple juego de ajedrez,
    votos: 0    karma: 12
  50. #50   #49
    Decir que GTK es una biblioteca ineficiente por un simple bug no es muy ilustrativo. Si me dijeras que GTK emplea un protocolo muy complejo con multitud de parámetros y funciones sobrantes, aún, pero probablemente en dicha lentitud colaborase el propio juego de ajedrez abusando de una función costosa, aunque luego se mejorase su rendimiento para permitir mayor carga.
    votos: 0    karma: 7
     *   Filiprino Filiprino
  51. #51   #50 ¿Y Qué me dices de GTKFileChooser y su "velocidad" a la hora de mostrar ficheros y directorios? Y no estoy troleando, porque GTK3 es relatvamente rápida pero en ese aspecto siguen igual...
    votos: 0    karma: 12
     *   Ander_ Ander_
  52. #52   #51
    Que ya te estás inventando demasiadas tonterías.
    votos: 0    karma: 7
  53. #53   #52 Hala, abre Thunar y vete a /usr/bin/ a ver cuanto tarda en mostrarte todo. Luego compáralo con cualquier programa QT4.

    GTK sigue siendo un desastre y no lo digo yo únicamente. Y dibujando siguen siendo lentas comparadas con EFL que te rula hasta en un cacharro empotrado de forma rápida.
    votos: 0    karma: 12
     *   Ander_ Ander_
  54. #55   #54
    Esa gráfica no dice nada, más reafirma mi comentario. Gtkperf es además un benchmark sintético y a pesar de ello el propio benchmark sintético muestra diferencias prácticamente nulas, incluyendo su ejecución en Ubuntu. Sin embargo sí que muestra el culpable principal: pango, que es el que se lleva una buena tostada de comunicación con X.org y sus minirespuestas junto con pixman, es por ello que hay tanto tiempo empleado en el núcleo linux (no-vmlinux).

    Entre temas GTK sólo hay un total de 6 ms de diferencia entre el lento y el rápido después de un ciclo completo (botón, checkbox, mostrar texto, dibujar varias cosas).

    Un protocolo más sencillo y eficiente de las X haría las cosas mucho más rápidas.

    Nota: número de ciclos no es lo mismo que número de instrucciones. El número de ciclos incluye también ciclos de espera mientras que el número de instrucciones no incluye ese dato.
    Wow, now the libpangoft2 library is on top! It issue the greatest number of instructions but, as it isn't the top CPU cycles burner, probably its instruction and data streams fit better into the processor's cache and/or can be executed faster by the CPU's out-of-order logic.
    votos: 1    karma: 19
     *   Filiprino Filiprino
  55. #56   #55 Repito que en lo de quitar TCP/IP de X estoy de acuerdo, pero la composición sigue sin convencerme. Y GTK3 con un tema ligero como mist es medio usable en un PC de 800MHZ, pero metele temas con dibujines y tal... y adíos.

    Con E no pasa, te lo explican mejor en 47 el porqué.

    GTK bajo wayland será más rápido, pero no gracias a la composición, si no al quitar sobrecarga.
    votos: 0    karma: 12
     *   Ander_ Ander_
comentarios cerrados

menéame