La réponse est compliquée:
1) en LAN, il y a plusieurs solutions:
a) client X --> serveur Wayland: ça marche déjà; tu peux avoir un serveur X comme client Wayland sur la machine serveur Wayland qui fait l'affichage, donc si ton application utilise X ou a un toolkit qui supporte à la fois X et Wayland, tu la mets en mode X, et c'est bon: la bande passante utilisée sera la même qu'à l'heure actuelle.
b) client Wayland --> serveur Wayland: ce n'est pas encore implémenter mais je pense que cela le sera: tu peux très bien envoyer l'image que génère ton application sur un "compositeur-proxy" Wayland qui l'enverra sur la machine serveur Wayland à un "client-relaye" Wayland (et vice versa pour les clicks de souris, clavier, etc).
La bande passante utilisée sera supérieure à celle utilisée par un client X mais l'avantage est que tu peux utiliser un toolkit "pur Wayland".
c) client Wayland --> serveur X: ça pourrait être utile pour la compatibilité, mais je ne sais pas trop si ça se fera, la bande passante utilisée serait la même que dans (b).
2) en WAN: et bien client X --> serveur Wayland ça marcherait aussi bien (aussi mal?) qu'X en WAN à l'heure actuelle (on peut même imaginer (X --> NX) --> (NX --> client Wayland --> serveur Wayland)).
Mais pour les autres cas, la bande passante utilisée sera trop élevée.
Donc en LAN pas de problème, le remote display en WAN là je ne sais pas trop comment ça va évoluer, si on est optimiste on peut se dire que X va se spécialiser pour l'affichage en WAN et va devenir meilleur dans ce cas là, si on est pessimiste on peut se dire que l'affichage en WAN passera de "pas terrible" (NX n'a même pas été intégrer à X!) à "encore pire"..
[^] # Re: remote display
Posté par reno . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 9.
La réponse est compliquée:
1) en LAN, il y a plusieurs solutions:
a) client X --> serveur Wayland: ça marche déjà; tu peux avoir un serveur X comme client Wayland sur la machine serveur Wayland qui fait l'affichage, donc si ton application utilise X ou a un toolkit qui supporte à la fois X et Wayland, tu la mets en mode X, et c'est bon: la bande passante utilisée sera la même qu'à l'heure actuelle.
b) client Wayland --> serveur Wayland: ce n'est pas encore implémenter mais je pense que cela le sera: tu peux très bien envoyer l'image que génère ton application sur un "compositeur-proxy" Wayland qui l'enverra sur la machine serveur Wayland à un "client-relaye" Wayland (et vice versa pour les clicks de souris, clavier, etc).
La bande passante utilisée sera supérieure à celle utilisée par un client X mais l'avantage est que tu peux utiliser un toolkit "pur Wayland".
c) client Wayland --> serveur X: ça pourrait être utile pour la compatibilité, mais je ne sais pas trop si ça se fera, la bande passante utilisée serait la même que dans (b).
2) en WAN: et bien client X --> serveur Wayland ça marcherait aussi bien (aussi mal?) qu'X en WAN à l'heure actuelle (on peut même imaginer (X --> NX) --> (NX --> client Wayland --> serveur Wayland)).
Mais pour les autres cas, la bande passante utilisée sera trop élevée.
Donc en LAN pas de problème, le remote display en WAN là je ne sais pas trop comment ça va évoluer, si on est optimiste on peut se dire que X va se spécialiser pour l'affichage en WAN et va devenir meilleur dans ce cas là, si on est pessimiste on peut se dire que l'affichage en WAN passera de "pas terrible" (NX n'a même pas été intégrer à X!) à "encore pire"..