Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.
Le compositeur systeme est quelque chose encore en debat. Il introduit des problemes de performance qu'on ne sait pas encore comment resoudre. Le principal probleme etant sur les inputs. Toutes les entrees/sorties devant etre controle par le compositeur systeme. Ca rajoute un process qui doit etre reveille et traverse avant, soit de pouvoir envoyer une action d'un peripherique vers le compositeur du desktop en cour, soit de pouvoir envoyer un buffer a l'ecran. Cela a un impact non negligeable et pas forcement utile au final. Pourquoi faut-il payer le prix chere pour si peu ?
Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur. De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente. C'est certes plus proche de l'infrastructure X actuelle, mais ça permet de factoriser beaucoup de code entre les DE (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).
Tout le monde reimplemente deja son propre compositeur. KWin, Compiz, Enlightenment, ... Tous les desktops un peu moderne ont deja se code. Et pour certain sont plus rapide que le code du compositeur se trouvant dans X ! Chacun utilise aussi un toolkit different et donc il n'y a que tres peu de code factorisable.
Le but de Weston est de fournir une implementation de reference pour Wayland, mais aussi de fournir un ensemble de bibliotheque agnostique du compositeur et de les maintenir pour le benefice de tout le monde. L'approche de Wayland permet d'avoir le maximum de performance possible tout en factorisant le code qui peut l'etre.
Mir de son cote ne travaillant pas du tout avec la communaute, il n'y a aucun travail reel de factorisation. C'est juste un decoupage arbitraire entre Unity et Mir qui est mis en place. Sans compter que je ne pense pas qu'ils ont les connaissance de l'ensemble de la communaute travaillant sur Wayland pour faire un compositeur aussi performant.
Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.
Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios. Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement, mais Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.
Bref, je suis assez pessimiste sur l'avenir de tout ça et j'ai besoin d'être rassuré par des gens qui s'y connaissent.
T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux... sans grand interet pour la communaute !
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 7.
Le compositeur systeme est quelque chose encore en debat. Il introduit des problemes de performance qu'on ne sait pas encore comment resoudre. Le principal probleme etant sur les inputs. Toutes les entrees/sorties devant etre controle par le compositeur systeme. Ca rajoute un process qui doit etre reveille et traverse avant, soit de pouvoir envoyer une action d'un peripherique vers le compositeur du desktop en cour, soit de pouvoir envoyer un buffer a l'ecran. Cela a un impact non negligeable et pas forcement utile au final. Pourquoi faut-il payer le prix chere pour si peu ?
Pour plus de lecture sur le sujet, je conseille cet excellent blog : https://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/ .
Tout le monde reimplemente deja son propre compositeur. KWin, Compiz, Enlightenment, ... Tous les desktops un peu moderne ont deja se code. Et pour certain sont plus rapide que le code du compositeur se trouvant dans X ! Chacun utilise aussi un toolkit different et donc il n'y a que tres peu de code factorisable.
Le but de Weston est de fournir une implementation de reference pour Wayland, mais aussi de fournir un ensemble de bibliotheque agnostique du compositeur et de les maintenir pour le benefice de tout le monde. L'approche de Wayland permet d'avoir le maximum de performance possible tout en factorisant le code qui peut l'etre.
Mir de son cote ne travaillant pas du tout avec la communaute, il n'y a aucun travail reel de factorisation. C'est juste un decoupage arbitraire entre Unity et Mir qui est mis en place. Sans compter que je ne pense pas qu'ils ont les connaissance de l'ensemble de la communaute travaillant sur Wayland pour faire un compositeur aussi performant.
Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios. Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement, mais Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.
T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux... sans grand interet pour la communaute !