Como ya sabemos KDE Next (o KDE 5 como prefieran) fue lanzado como estable hace algunos días y entre las novedades que trae consigo, una de las más comentadas es el nuevo Artwork llamado Breeze.
Los que ya han probado esta nueva versión o han visto el video, se habrán podido percatar de que en el caso del decorador de ventanas, el que viene por defecto es Oxygen y no Breeze. Pues bien Martin Gräßlin nos explica en su blog cual es el motivo de esta decisión.
Como el artículo está en Inglés, trataré de llevarles a ustedes la idea fundamental de esto.
¿Por que Breeze no viene por defecto?
Empiezo con la explicación de cómo funcionan las decoraciones de las ventanas en KWin 4. KWin es el llamado re-parenting de los gestores de ventanas. Esto significa que la ventana gestionada por X11 se pone en otra ventana X11 que proporciona el marco de la ventana. En KWin utilizamos QWidget para el marco de la ventana. Por lo tanto nosotros también estamos restringidos a lo QWidget nos proporciona… Nuestra solución es interceptar todos los eventos de pintura de la decoración en QWidget y suprimirlo, desencadenar un repintado del compositor y en el paso de representación garantizar los decoración de una imagen temporal que luego se copia en una textura.
La decoración de la ventana del tema Breeze se basa en el motor del tema Aurorae. Como yo soy el autor principal de Aurorae puedo golpearlo en esta entrada del blog sin sentirme mal por ello
Aurorae fue diseñado para que sea muy fácil de crear una decoración y hacer uso de las nuevas características de translucidez. Siendo una solución que podría ser utilizado como decoración por defecto, pero nunca fue su objetivo. La idea era permitir a los usuarios que desean la personalización esta función, mientras que la mayoría de los usuarios puede utilizar los temas nativos que son más rápidos. Aurorae nunca fue rápido y no será rápido.
Ahora en KWin 5, el uso de QML es el principal problema que hace que sea difícil de usar Aurorae. QtQuick utiliza el Scenegraph y utiliza QWindows en lugar de QWidget. Eso es un fastidio para nuestra API basada QWidget. Ajustamos el uso interno para apoyar decoraciones basadas en QWindows, pero eso fue todo un camino difícil, ya que hay diferencias en el comportamiento de las ventanas. Como ya no se basa en QWidget, nuestra interceptación de eventos de pintura se rompe y necesitábamos una nueva solución para ello. Y esta solución es aún más fea que la anterior porque QtQuick está actualmente funcionando a través de OpenGL. Debido a las limitaciones en la aplicación OpenGL Qt (podrían ser abordados en Qt 5.4) que no podemos compartir con el contexto OpenGL utilizado por QtQuick… Esto no sólo es una enorme sobrecarga al copiar el contenido de la GPU a la memoria RAM y de nuevo a la GPU, también está perdiendo una gran cantidad de memoria. En caso de una ventana maximizada no es sólo la barra de título, pero la ventana completa. Y existe esa sobrecarga para cada ventana.
Eso por sí solo puede hacer Aurorae totalmente inutilizable. Actualmente estoy usando el tema Breeze y KWin necesita de más de 200 MB de RAM – no es realmente aceptable. Pero la situación es aún peor. Con QWindows no conseguimos saber qué áreas consiguieron actualizarse. Así que cuando, por ejemplo, un botón se actualiza tenemos que volver a pintar la ventana completa, incluyendo la copia completa del contenido de la decoración. Que sobre todo en situaciones de animación es un gran problema.
¿Entonces cuál es el camino a seguir? Empecé a implementar una nueva decoración para el API eliminando la restricción de la decoración basado en el bienestar de QWidget y al mismo tiempo empecé a implementar la decoración de Breeze con esta nueva API. Espero que podamos introducir esto en KWin 5.1.
Y así son las cosas señores. Espero que se entienda más o menos cual es el problema. Voy a preguntarle a Martin si no es más práctico y rápido hacer el tema de Breeze nativo al igual que Oxygen, aunque de momento a mi no me preocupa, Oxygen aunque no es lo más lindo del mundo, tiene un montón de opciones..
The post Breeze: ¿Por qué no viene por defecto en KDE 5? appeared first on Desde Linux.
Continúar leyendo...
Los que ya han probado esta nueva versión o han visto el video, se habrán podido percatar de que en el caso del decorador de ventanas, el que viene por defecto es Oxygen y no Breeze. Pues bien Martin Gräßlin nos explica en su blog cual es el motivo de esta decisión.
Como el artículo está en Inglés, trataré de llevarles a ustedes la idea fundamental de esto.
¿Por que Breeze no viene por defecto?
Empiezo con la explicación de cómo funcionan las decoraciones de las ventanas en KWin 4. KWin es el llamado re-parenting de los gestores de ventanas. Esto significa que la ventana gestionada por X11 se pone en otra ventana X11 que proporciona el marco de la ventana. En KWin utilizamos QWidget para el marco de la ventana. Por lo tanto nosotros también estamos restringidos a lo QWidget nos proporciona… Nuestra solución es interceptar todos los eventos de pintura de la decoración en QWidget y suprimirlo, desencadenar un repintado del compositor y en el paso de representación garantizar los decoración de una imagen temporal que luego se copia en una textura.
La decoración de la ventana del tema Breeze se basa en el motor del tema Aurorae. Como yo soy el autor principal de Aurorae puedo golpearlo en esta entrada del blog sin sentirme mal por ello
Aurorae fue diseñado para que sea muy fácil de crear una decoración y hacer uso de las nuevas características de translucidez. Siendo una solución que podría ser utilizado como decoración por defecto, pero nunca fue su objetivo. La idea era permitir a los usuarios que desean la personalización esta función, mientras que la mayoría de los usuarios puede utilizar los temas nativos que son más rápidos. Aurorae nunca fue rápido y no será rápido.Ahora en KWin 5, el uso de QML es el principal problema que hace que sea difícil de usar Aurorae. QtQuick utiliza el Scenegraph y utiliza QWindows en lugar de QWidget. Eso es un fastidio para nuestra API basada QWidget. Ajustamos el uso interno para apoyar decoraciones basadas en QWindows, pero eso fue todo un camino difícil, ya que hay diferencias en el comportamiento de las ventanas. Como ya no se basa en QWidget, nuestra interceptación de eventos de pintura se rompe y necesitábamos una nueva solución para ello. Y esta solución es aún más fea que la anterior porque QtQuick está actualmente funcionando a través de OpenGL. Debido a las limitaciones en la aplicación OpenGL Qt (podrían ser abordados en Qt 5.4) que no podemos compartir con el contexto OpenGL utilizado por QtQuick… Esto no sólo es una enorme sobrecarga al copiar el contenido de la GPU a la memoria RAM y de nuevo a la GPU, también está perdiendo una gran cantidad de memoria. En caso de una ventana maximizada no es sólo la barra de título, pero la ventana completa. Y existe esa sobrecarga para cada ventana.
Eso por sí solo puede hacer Aurorae totalmente inutilizable. Actualmente estoy usando el tema Breeze y KWin necesita de más de 200 MB de RAM – no es realmente aceptable. Pero la situación es aún peor. Con QWindows no conseguimos saber qué áreas consiguieron actualizarse. Así que cuando, por ejemplo, un botón se actualiza tenemos que volver a pintar la ventana completa, incluyendo la copia completa del contenido de la decoración. Que sobre todo en situaciones de animación es un gran problema.
¿Entonces cuál es el camino a seguir? Empecé a implementar una nueva decoración para el API eliminando la restricción de la decoración basado en el bienestar de QWidget y al mismo tiempo empecé a implementar la decoración de Breeze con esta nueva API. Espero que podamos introducir esto en KWin 5.1.
Y así son las cosas señores. Espero que se entienda más o menos cual es el problema. Voy a preguntarle a Martin si no es más práctico y rápido hacer el tema de Breeze nativo al igual que Oxygen, aunque de momento a mi no me preocupa, Oxygen aunque no es lo más lindo del mundo, tiene un montón de opciones..
The post Breeze: ¿Por qué no viene por defecto en KDE 5? appeared first on Desde Linux.
Continúar leyendo...