Comme l'article en sujet est partial, j'ai noté les problèmes suivants que je liste:
1) L'article dit "X a 4 sous-systèmes d'entrée", sauf qu'une version a été éliminée donc un article moins partial dirait "X a 3 sous-systèmes d'entrée", c'est déjà bien trop pas la peine d'en rajouter.
2) X a été presque un OS, c'est vrai certes mais c'est une critique de l'implémentation pas du protocole ce que cet article mélange allègrement: la preuve ce n'est plus vrai et le protocole n'a pas changé!
3) La gestion des fontes, l'article "oublie" de parler de l'extension XRender et de son caches des glyphes, un mécanisme efficace pour avoir des fontes dessinées par le client mais permettant l'affichage de texte en distant en envoyant peu de donnée (beaucoup moins que l'envoi de gros buffers comme Wayland), évidemment ça ne rentre pas dans le parti-pris de l'article donc c'est zappé.
4) Wayland n'a pas d'API de dessin, certes c'est plus simple mais ça peu aussi être moins efficace en distant: soit on envoi des gros buffers (très consommateurs en bande passante plus qu'un film puisque non compressé!), soit on les compresse mais la compression ça prend du temps donc on ajoute encore de la latence (compression et décompression), dommage la latence est le problème numéro 1 en distant!
5) "La devise de Wayland est « Chaque image est parfaite »", bon c'est vrai dans la majorité des cas, mais on peu trouver des cas (rare heureusement) où l'architecture de Wayland va créer un problème: certains écrans bizarre ont des sous-pixels qui sont différents suivant l'emplacement (pas invariant par translation) et Wayland n'indique pas aux programmes où leurs fenêtres vont être affichées du coup les programmes ne peuvent pas exploiter correctement les sous-pixels dans ce cas là.
Quoi c'est tiré par les cheveux?
Bah l'article aussi!
La fin étant spécialement grandiose:
6) Il dit qu'X n'est pas indépendant du réseau car il a des extensions qui ne sont pas indépendantes du réseau, si ça n'est de la mauvaise foi..
7) L'article décris X comme étant synchrone alors qu'XCB est asynchrone, mettre sur le dos d'X la lenteur des toolkits a passé d'XLib à XCB..
8) Pour ce qui est d'être meilleur qu'X a distance, euh ça dépend, pour afficher quoi?
Pas pour afficher du texte à distance en tout cas, cf (3)!
Au cas où certains se poseraient la question: je ne suis pas anti-Wayland, je trouve juste dommage que le minimalisme à tout prix de Wayland va fort probablement réduire les performances pour l'affichage de texte en distant et j'attends de voir comment va marcher une application Gnome/Wayland avec un compositeur KDE/Wayland, à terme je pense que ça fonctionnera bien, mais sur le cours terme l'intégration risque d'être "intéressante"..
# Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 10.
Comme l'article en sujet est partial, j'ai noté les problèmes suivants que je liste:
1) L'article dit "X a 4 sous-systèmes d'entrée", sauf qu'une version a été éliminée donc un article moins partial dirait "X a 3 sous-systèmes d'entrée", c'est déjà bien trop pas la peine d'en rajouter.
2) X a été presque un OS, c'est vrai certes mais c'est une critique de l'implémentation pas du protocole ce que cet article mélange allègrement: la preuve ce n'est plus vrai et le protocole n'a pas changé!
3) La gestion des fontes, l'article "oublie" de parler de l'extension XRender et de son caches des glyphes, un mécanisme efficace pour avoir des fontes dessinées par le client mais permettant l'affichage de texte en distant en envoyant peu de donnée (beaucoup moins que l'envoi de gros buffers comme Wayland), évidemment ça ne rentre pas dans le parti-pris de l'article donc c'est zappé.
4) Wayland n'a pas d'API de dessin, certes c'est plus simple mais ça peu aussi être moins efficace en distant: soit on envoi des gros buffers (très consommateurs en bande passante plus qu'un film puisque non compressé!), soit on les compresse mais la compression ça prend du temps donc on ajoute encore de la latence (compression et décompression), dommage la latence est le problème numéro 1 en distant!
5) "La devise de Wayland est « Chaque image est parfaite »", bon c'est vrai dans la majorité des cas, mais on peu trouver des cas (rare heureusement) où l'architecture de Wayland va créer un problème: certains écrans bizarre ont des sous-pixels qui sont différents suivant l'emplacement (pas invariant par translation) et Wayland n'indique pas aux programmes où leurs fenêtres vont être affichées du coup les programmes ne peuvent pas exploiter correctement les sous-pixels dans ce cas là.
Quoi c'est tiré par les cheveux?
Bah l'article aussi!
La fin étant spécialement grandiose:
6) Il dit qu'X n'est pas indépendant du réseau car il a des extensions qui ne sont pas indépendantes du réseau, si ça n'est de la mauvaise foi..
7) L'article décris X comme étant synchrone alors qu'XCB est asynchrone, mettre sur le dos d'X la lenteur des toolkits a passé d'XLib à XCB..
8) Pour ce qui est d'être meilleur qu'X a distance, euh ça dépend, pour afficher quoi?
Pas pour afficher du texte à distance en tout cas, cf (3)!
Au cas où certains se poseraient la question: je ne suis pas anti-Wayland, je trouve juste dommage que le minimalisme à tout prix de Wayland va fort probablement réduire les performances pour l'affichage de texte en distant et j'attends de voir comment va marcher une application Gnome/Wayland avec un compositeur KDE/Wayland, à terme je pense que ça fonctionnera bien, mais sur le cours terme l'intégration risque d'être "intéressante"..