Euh, je crois qu'il y a un truc que tu as loupe. Avec Wayland, tu es oblige de passer par un composite manager, avec X ce n'est pas le cas. Donc pour etre fairplay, il faut comparer X + composite manager avec Wayland + composite manager.
La synchro avec la vsync et ce genre de chose, c'est le boulot du composite manager, et mon composite manager X, il le fait tres bien quand je le lui demande.
Le deuxieme point, la lenteur des applications et du temps a se rafraichir, tout d'abord avec un composite manager, tu peux laisser tout le temps que tu veux a l'application pour se reafficher, vu que tu as le contenu de la precedente frame pour bosser... Super solution, au lieu de faire en sorte qu'une appli aille vite et ne bloque jamais l'affichage...
Pareil XCB, c'est une bonne evolution, mais ca ne changera rien a la majorite des applications. Le seul qui peut y gagner avec xcb, c'est ton window manager, qui a moins d'aller/retour a faire pour creer des fenetres. Pour une application, ca ne changera juste rien.
Le probleme n'est pas dans X, mais dans des toolkits graphiques mal ecrit et qui ne savent pas faire un pipeline de rendu 2D correct. Avant de tapper sur les drivers/X, il faut commencer par coder correctement les toolkits. Et il faut aller prendre l'inspiration chez des gens qui font des trucs perfomants... les jeux. Copier le pipeline de rendu d'un jeu moderne, c'est ca qui donnera des perfs a vos applications. Switcher a Wayland ne changera rien.
Pour rassurer tout le monde, je pense que les travaux commence enfin dans QT avec l'utilisation de techno comme QML qui permette de completement abstraire un SceneGraphe permettra enfin de se diriger pour ce toolkit vers des performances honorable. Je suis par contre plus dubitatif pour GTK qui ne me semble plus avoir ce genre de projet a l'ordre du jour. Enfin si vous voulez voir la difference, il y a les EFL et E17 pour avoir une architecture efficace graphiquement. La preuve, il est possible de faire tourner un composite manager en software sur un EEE 701. Comme quoi, le probleme a ete mal identifie.
Et sinon le rapport entre synchrone et multicoeur, faudra aussi que tu m'expliques ? Parce que la technique pour tirer au mieux parti de ton CPU multicoeur, c'est qu'une fois toutes les ressources de la frame a dessine locke, tu declenches le rendu dans un thread separe de maniere a pouvoir retourner le plus rapidement possible a la logique de ton appli.
[^] # Re: j'approuve
Posté par cedric . En réponse au journal Ubuntu abandonne X pour Wayland. Évalué à 10.
La synchro avec la vsync et ce genre de chose, c'est le boulot du composite manager, et mon composite manager X, il le fait tres bien quand je le lui demande.
Le deuxieme point, la lenteur des applications et du temps a se rafraichir, tout d'abord avec un composite manager, tu peux laisser tout le temps que tu veux a l'application pour se reafficher, vu que tu as le contenu de la precedente frame pour bosser... Super solution, au lieu de faire en sorte qu'une appli aille vite et ne bloque jamais l'affichage...
Pareil XCB, c'est une bonne evolution, mais ca ne changera rien a la majorite des applications. Le seul qui peut y gagner avec xcb, c'est ton window manager, qui a moins d'aller/retour a faire pour creer des fenetres. Pour une application, ca ne changera juste rien.
Le probleme n'est pas dans X, mais dans des toolkits graphiques mal ecrit et qui ne savent pas faire un pipeline de rendu 2D correct. Avant de tapper sur les drivers/X, il faut commencer par coder correctement les toolkits. Et il faut aller prendre l'inspiration chez des gens qui font des trucs perfomants... les jeux. Copier le pipeline de rendu d'un jeu moderne, c'est ca qui donnera des perfs a vos applications. Switcher a Wayland ne changera rien.
Pour rassurer tout le monde, je pense que les travaux commence enfin dans QT avec l'utilisation de techno comme QML qui permette de completement abstraire un SceneGraphe permettra enfin de se diriger pour ce toolkit vers des performances honorable. Je suis par contre plus dubitatif pour GTK qui ne me semble plus avoir ce genre de projet a l'ordre du jour. Enfin si vous voulez voir la difference, il y a les EFL et E17 pour avoir une architecture efficace graphiquement. La preuve, il est possible de faire tourner un composite manager en software sur un EEE 701. Comme quoi, le probleme a ete mal identifie.
Et sinon le rapport entre synchrone et multicoeur, faudra aussi que tu m'expliques ? Parce que la technique pour tirer au mieux parti de ton CPU multicoeur, c'est qu'une fois toutes les ressources de la frame a dessine locke, tu declenches le rendu dans un thread separe de maniere a pouvoir retourner le plus rapidement possible a la logique de ton appli.