Dans le design wayland tu as un serveur (weston) qui fait 90% du boulot dans un seul process qui a une vision global de l'état courant de l'ensemble des applications. Dans le design mir, la majeur partie est dans unity (du moins c'est l'impression que donne actuellement le code et les commentaires des gens impliqués dans mir), bref cela ressemble beaucoup plus a X11 + compositeur ou le compositeur est un process séparé qui ne sait pas forcement tout et qui doit parler avec mir et les applications.
mir semble par ailleurs bien plus limité sur l'aspect graphique, visiblement pas de concept de sub-surface/region, ni de concept pour le damage d'une region ou l'opacité. Deux choses qui permettent au serveur wayland (par exemple weston) de réaliser des optimisations qui permettent de sauver beaucoup d'énergie. C'est peut être juste parce que mir n'a pas encore implémenté tout ca mais cela semble plus être le résultat de leur design bien plus limité.
Je n'irai pas plus loin sur l'aspect input parce que je suis bien moins familier sur le domaine mais ce que j'entends de la part de personne que j'estime les plus compétentes sur ce sujet dans l'univers du libre ne me rassure pas et conforte l'opinion que j'ai formé après avoir regardé la partie graphique de mir. La partie transformation des inputs par exemple semble totalement absent.
Oui wayland ne fait pas grand chose, comme souvent j'abuse du mot wayland pour parler de l'ensemble de l'ecosystème et dans ce cas particulier du serveur wayland dont une des implémentations est weston. Mais c'est pour moi le point central, weston fait beaucoup de chose mais ils les fait bien et de manière simple parcequ'il a toute les informations nécessaire. Dans le couple unity/mir les informations sont partagés entre les deux ce qui conduira inévitablement a avoir l'un des deux sans l'information que l'autre a.
[^] # Re: Differences ?
Posté par glisse . En réponse au journal Canonical: les fouteurs de merde, le retour. Évalué à 10.
Dans le design wayland tu as un serveur (weston) qui fait 90% du boulot dans un seul process qui a une vision global de l'état courant de l'ensemble des applications. Dans le design mir, la majeur partie est dans unity (du moins c'est l'impression que donne actuellement le code et les commentaires des gens impliqués dans mir), bref cela ressemble beaucoup plus a X11 + compositeur ou le compositeur est un process séparé qui ne sait pas forcement tout et qui doit parler avec mir et les applications.
mir semble par ailleurs bien plus limité sur l'aspect graphique, visiblement pas de concept de sub-surface/region, ni de concept pour le damage d'une region ou l'opacité. Deux choses qui permettent au serveur wayland (par exemple weston) de réaliser des optimisations qui permettent de sauver beaucoup d'énergie. C'est peut être juste parce que mir n'a pas encore implémenté tout ca mais cela semble plus être le résultat de leur design bien plus limité.
http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/include/mir_toolkit/mir_client_library.h
Je n'irai pas plus loin sur l'aspect input parce que je suis bien moins familier sur le domaine mais ce que j'entends de la part de personne que j'estime les plus compétentes sur ce sujet dans l'univers du libre ne me rassure pas et conforte l'opinion que j'ai formé après avoir regardé la partie graphique de mir. La partie transformation des inputs par exemple semble totalement absent.
Oui wayland ne fait pas grand chose, comme souvent j'abuse du mot wayland pour parler de l'ensemble de l'ecosystème et dans ce cas particulier du serveur wayland dont une des implémentations est weston. Mais c'est pour moi le point central, weston fait beaucoup de chose mais ils les fait bien et de manière simple parcequ'il a toute les informations nécessaire. Dans le couple unity/mir les informations sont partagés entre les deux ce qui conduira inévitablement a avoir l'un des deux sans l'information que l'autre a.