Il me semble que la complétude est vérifié aussi en Ada: "In Ada, one advantage of the case statement is that the compiler will check the coverage of the choices, that is, all the values of the subtype of variable X must be present or a default branch when others must specify what to do in the remaining cases."
S'auto heberger pour echapper a l'emprise de Google (comme suggeré par la presentation) pour ensuite synchroniser ses donnees avec Google, c'est un peu ironique, non?
Tu réponds à qui là? Parce que si c'est à moi, je t'invite a relire ce que j'ai marqué, déplacer une fenêtre peut se faire purement coté serveur avec Weston.
Hum, si le gars est capable de miniaturiser un ordinateur suffisamment puissant pour lui donner un réel avantage aux échecs ET en plus de le mettre sous la peau, pas besoin pour lui de jouer aux échecs: il peut être milliardaire demain.
A condition de placer les conditions de base - qui correspondent à ce que l'on veut faire :[coupé]une fenêtre de 300x300 que l'on déplace sur le bureau pendant 10s.
Hein???
Avec Wayland, les applications
1) envoient les buffers entiers contenant leur fenêtre
2) ne connaissent pas leur coordonnées
donc déplacer une fenêtre peut se faire uniquement coté serveur (modulo les histoires de décoration des fenêtres qui sont gérées elle par le client), pourquoi envoyer un écran complet à un affichage distant lorsqu'on déplace une fenêtre?
C'est une implémentation possible ok mais carrément sous-optimal par rapport à ce que le protocole Wayland te permet..
Euh pourquoi?? Tu peux faire un cache des bitmap de glyphes à la XRender.
Ça marche moins bien dans certain cas (traitement de texte qui déforme les caractères suivant leur environnement) mais ça reste très probablement bien supérieur à "je mélange tout" puis j'essaye de compresser le bazar résultant sans être très compliqué..
Le H.264 peut aussi compresser sans perte, mais dans ce cas c'est beaucoup trop lourd.
Et c'est pour ça que d'un point "accès à distance" envoyer les commandes de dessin et non pas le buffer a de l'intérêt..
Ceci dit, un écran d'ordinateur ce n'est pas une caméra donc une compression spécifique (comme celle prototypée par Kristian Høgsberg) pourrait être supérieure après ça ajoute toujours de la latence..
Sinon, étant donné qu'en 2013 la moindre puce ARM à 50 euros intègre un chipset graphique capable d'encoder en H264 en temps réel en 1080px30 fps
Sauf que tu peux déjà acheté un moniteur avec une résolution supérieure..
Et que le 4k va bientôt arriver.
En plus le H264 c'est une compression avec perte pas terrible pour afficher du texte!
qui permettrait au client de déporter le dessin sur le serveur…
Techniquement c'est possible, quoique pas si simple:
1) il faut pouvoir 'synchroniser' l'envoi d'une image normale et d'une image vectorielle superposée, il me semble que dans leur modèle de dessin de "subsurface" les subsurfaces sont disjointes (pas sûr)..
2) il faut trouver le 'bon' jeu d'instructions vectorielles: SVG me parait beaucoup, beaucoup trop gros!
Maintenant comme ça ne rentre pas dans la philosophie du "tout client" je doute que ça ait une chance de rentrer dans le protocole 'standard'.
Un jour, il a dit ça : « Il vaut mieux faire pitié qu'envie ».
J'aime bien ce proverbe retourné, transformé en maxime à la Gandhi, et je comprends ça comme une politique de la liberté, que je rapproche spontanément du monde qui nous occupe dans ces pages && || nos vies : ).
Ah? Moi je prends ça comme un jeu de mot pas terrible: beau sur le papier (car surprenant) mais faux à ~90%.
Sauf que dans le cas du traitement de texte, tu vas vouloir avoir un controle tres fin du rendu,[coupé] Donc je parie que tu ne passes pas aujourd'hui par XRender.
Ça dépend beaucoup du traitement de texte(!), pour pas mal de notepad et consort chaque caractère a un rendu unique où le "glyph cache" fonctionnerait très bien.
sans compter que en terme de performance, c'est du texte que tu veux lire, donc tu n'es pas a vouloir le faire défiler a grande vitesse.
Faux, on passe aussi pas mal de temps à faire défiler rapidement du texte qu'on ne veut pas lire pour arriver à la section qui nous intéresse..
Je parle de la bande passante utilisée et de la latence en accès distant, tu parles des performances en local: je ne vois pas le rapport?
Oui en local utiliser XRender n'a pas de sens, en distant par contre c'est le contraire: se restreindre a envoyer des gros buffer (et avoir soit une grosse utilisation de bande passante, soit une latence dégradée à cause de la compression) est sous-optimal.
j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???
Je pense effectivement que c'est ce qui va se passer, les utilisateurs qui avaient l'habitude d'exporter leur terminal passeront par ssh à la place.
Ça ne me pose pas de problème particulier, mais c'est juste un peu pénible d'entendre des Wayland fanboy, dire X c'est tout pourri(vrai), Wayland c'est génial: presque vrai mais uniquement dans 90% des cas, ce n'est pas être contre Wayland que de dire Wayland c'est génial sauf pour exporter du texte en distant ou là (à priori) il vaudra mieux utiliser ssh ou NX (donc X).
Pas d'accord:dire que c'est un combat, c'est rentrer dans le jeu de l'article/troll…
Quand on choisit entre plusieurs solutions on regarde tout les avantages et inconvénients, quand on ne regarde que les inconvénients de X et les avantages de Wayland, bah c'est bien du Phoronix..
Pour GTK le manque de main d'oeuvre est criant, pour Qt il y a un mode XRender (mais ce n'est pas le mode par défaut), un jour où je serai a la retraite (dans 25 ans) ça pourrait m'amuser de comparer les performances en réseau entre ces 2 modes.
Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..
Mauvais toolkits, problème d'X??
C'est un peu la même problématique que pour XCB, XLib était pourri OK donc les devs X ont créer XCB (1ère version en 2001, Wayland a été commencé en 2008 et Qt5 va supporter les deux en même temps, chercher l'erreur??) mais les toolkits ne l'adoptent pas, c'est de la faute d'X??
Ma remarque sur les écrans haute définition qui arrivent bientôt (très bientôt même si le 4K prend) s'applique, et là soit on pourra augmenter la compression de buffer à Wayland (dommage pour la latence), soit .. revenir à un système à la X (enfin en supposant que les toolkits fassent bien leur boulot).
Certes, note qu'en distant avec Wayland si tu utilise OpenGL, le client va écrire dans la mémoire locale de son GPU puis recopier en RAM pour l'envoyer par le réseau (ta carte Ethernet ne peut pas accéder à la VRAM) à la RAM du serveur d'affichage qui va ensuite le transférer dans la mémoire de son GPU , alors qu'avec X le client envois la commande au serveur d'affichage qui va utiliser OpenGL pour écrire directement dans la mémoire du GPU.
Alors avec les écran haute résolution qui devraient finir par se démocratiser, Wayland plus efficace qu'X en distant?
Hum, j'ai un gros doute.
Oui sur le redimensionnement des fenêtres Weston attend la fenêtre complète calculée par le client avant de l'afficher, donc si le client est lent ça peut saccader, ce qui sera bien pénible en effet!
Après je crois que KDE veut gérer la décoration des fenêtres coté serveurs d'affichage donc il est possible qu'ils gardent la technique actuelle 'fluide mais parfois moche' plutôt que 'parfait mais saccadé'.
Au moins pour déplacer les fenêtre Weston le fait tout seul donc ça devrait être fluide, c'est toujours ça!
C'est une question intéressante..
Je sais que pour le Raspberry Pi ils ont utilisé l'accélération spécifique 2D de la carte à la place d'EGL, maintenant ça ne répond pas forcément à ta question je ne sais pas car je ne sais pas où ils ont utilisé l'accélération 2D: c'est peut-être uniquement dans le serveur et ta question est pour la communication client -> serveur d'affichage, le client peut-il préparer les buffers en utilisant de l'accélération 2D?
Est-ce vraiment un point important de l'affichage distant ?
Difficile à dire pour de bon tant que Wayland n'a pas un affichage distant fonctionnel ce qui permettrait de faire des vrais comparaisons, mais je pense que oui: avoir un mécanisme pour envoyer le texte séparément du fond permettrait de bien mieux traiter(compresser) chacun des 2 séparément (compression normal pour le fond et cache "à la XRender" pour les fontes) plutôt qu'une fois que tout a été mis dans un même buffer.
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"..
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 2.
Pas vraiment imposée: pour ajouter à Ruby/Python: Scala, Go, Rust, Nimrod (etc) ont pas vraiment avec une syntaxe C-like.
[^] # Re: langage fonctionnel
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 3.
Il me semble que la complétude est vérifié aussi en Ada: "In Ada, one advantage of the case statement is that the compiler will check the coverage of the choices, that is, all the values of the subtype of variable X must be present or a default branch when others must specify what to do in the remaining cases."
Donc je pense que tu as répondu un peu vite..
[^] # Re: docs
Posté par reno . En réponse à la dépêche L'auto-hébergement à l'honneur sur Perpignan. Évalué à 0.
C'est pragmatique surtout..
[^] # Re: 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é à 2.
Et si tu lisais la suite tu verrais que ta réponse n'a pas grand sens (en tout cas à ce qu'il me semble).
[^] # Re: 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é à 2.
Tu réponds à qui là? Parce que si c'est à moi, je t'invite a relire ce que j'ai marqué, déplacer une fenêtre peut se faire purement coté serveur avec Weston.
[^] # Re: Faut le mettre dans une cage !
Posté par reno . En réponse au journal [HS] L'homme bionique est arrivé !. Évalué à 10.
Hum, si le gars est capable de miniaturiser un ordinateur suffisamment puissant pour lui donner un réel avantage aux échecs ET en plus de le mettre sous la peau, pas besoin pour lui de jouer aux échecs: il peut être milliardaire demain.
Un récepteur radio par contre..
[^] # Re: 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é à 3.
Hein???
Avec Wayland, les applications
1) envoient les buffers entiers contenant leur fenêtre
2) ne connaissent pas leur coordonnées
donc déplacer une fenêtre peut se faire uniquement coté serveur (modulo les histoires de décoration des fenêtres qui sont gérées elle par le client), pourquoi envoyer un écran complet à un affichage distant lorsqu'on déplace une fenêtre?
C'est une implémentation possible ok mais carrément sous-optimal par rapport à ce que le protocole Wayland te permet..
[^] # Re: 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é à 2.
Euh pourquoi?? Tu peux faire un cache des bitmap de glyphes à la XRender.
Ça marche moins bien dans certain cas (traitement de texte qui déforme les caractères suivant leur environnement) mais ça reste très probablement bien supérieur à "je mélange tout" puis j'essaye de compresser le bazar résultant sans être très compliqué..
[^] # Re: 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é à 2.
Et c'est pour ça que d'un point "accès à distance" envoyer les commandes de dessin et non pas le buffer a de l'intérêt..
Ceci dit, un écran d'ordinateur ce n'est pas une caméra donc une compression spécifique (comme celle prototypée par Kristian Høgsberg) pourrait être supérieure après ça ajoute toujours de la latence..
[^] # Re: 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é à 3.
Sauf que tu peux déjà acheté un moniteur avec une résolution supérieure..
Et que le 4k va bientôt arriver.
En plus le H264 c'est une compression avec perte pas terrible pour afficher du texte!
# Bof
Posté par reno . En réponse au journal Déclaration de dépendance du cyberspace. Évalué à 3.
Ce n'est pas parce que quelqu'un se pignole en se gargarisant de grand mots qu'il faut faire la même chose, même pour démonter ses arguments foireux.
[^] # Re: 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é à 2.
Techniquement c'est possible, quoique pas si simple:
1) il faut pouvoir 'synchroniser' l'envoi d'une image normale et d'une image vectorielle superposée, il me semble que dans leur modèle de dessin de "subsurface" les subsurfaces sont disjointes (pas sûr)..
2) il faut trouver le 'bon' jeu d'instructions vectorielles: SVG me parait beaucoup, beaucoup trop gros!
Maintenant comme ça ne rentre pas dans la philosophie du "tout client" je doute que ça ait une chance de rentrer dans le protocole 'standard'.
# Ah?
Posté par reno . En réponse au journal Maurice Nadeau bronsonisé.. Évalué à 4.
Ah? Moi je prends ça comme un jeu de mot pas terrible: beau sur le papier (car surprenant) mais faux à ~90%.
[^] # Re: 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é à 1.
Ça dépend beaucoup du traitement de texte(!), pour pas mal de notepad et consort chaque caractère a un rendu unique où le "glyph cache" fonctionnerait très bien.
Faux, on passe aussi pas mal de temps à faire défiler rapidement du texte qu'on ne veut pas lire pour arriver à la section qui nous intéresse..
[^] # Re: 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é à 1.
Je parle de la bande passante utilisée et de la latence en accès distant, tu parles des performances en local: je ne vois pas le rapport?
Oui en local utiliser XRender n'a pas de sens, en distant par contre c'est le contraire: se restreindre a envoyer des gros buffer (et avoir soit une grosse utilisation de bande passante, soit une latence dégradée à cause de la compression) est sous-optimal.
Je pense effectivement que c'est ce qui va se passer, les utilisateurs qui avaient l'habitude d'exporter leur terminal passeront par ssh à la place.
Ça ne me pose pas de problème particulier, mais c'est juste un peu pénible d'entendre des Wayland fanboy, dire X c'est tout pourri(vrai), Wayland c'est génial: presque vrai mais uniquement dans 90% des cas, ce n'est pas être contre Wayland que de dire Wayland c'est génial sauf pour exporter du texte en distant ou là (à priori) il vaudra mieux utiliser ssh ou NX (donc X).
[^] # Re: Combat ?
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Pas d'accord:dire que c'est un combat, c'est rentrer dans le jeu de l'article/troll…
Quand on choisit entre plusieurs solutions on regarde tout les avantages et inconvénients, quand on ne regarde que les inconvénients de X et les avantages de Wayland, bah c'est bien du Phoronix..
[^] # Re: 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é à -1.
Pour GTK le manque de main d'oeuvre est criant, pour Qt il y a un mode XRender (mais ce n'est pas le mode par défaut), un jour où je serai a la retraite (dans 25 ans) ça pourrait m'amuser de comparer les performances en réseau entre ces 2 modes.
[^] # Re: 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é à 0.
Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..
[^] # Re: 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é à 0.
Mauvais toolkits, problème d'X??
C'est un peu la même problématique que pour XCB, XLib était pourri OK donc les devs X ont créer XCB (1ère version en 2001, Wayland a été commencé en 2008 et Qt5 va supporter les deux en même temps, chercher l'erreur??) mais les toolkits ne l'adoptent pas, c'est de la faute d'X??
Ma remarque sur les écrans haute définition qui arrivent bientôt (très bientôt même si le 4K prend) s'applique, et là soit on pourra augmenter la compression de buffer à Wayland (dommage pour la latence), soit .. revenir à un système à la X (enfin en supposant que les toolkits fassent bien leur boulot).
[^] # Re: CAO paramétrique
Posté par reno . En réponse au journal Impression 3d : oui mais avant, il faut bien dessiner mon enfant. Évalué à 2.
Tu n'es pas le seul a recommander OpenSCAD: http://lwn.net/Articles/550932/
[^] # Re: 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é à 1.
Certes, note qu'en distant avec Wayland si tu utilise OpenGL, le client va écrire dans la mémoire locale de son GPU puis recopier en RAM pour l'envoyer par le réseau (ta carte Ethernet ne peut pas accéder à la VRAM) à la RAM du serveur d'affichage qui va ensuite le transférer dans la mémoire de son GPU , alors qu'avec X le client envois la commande au serveur d'affichage qui va utiliser OpenGL pour écrire directement dans la mémoire du GPU.
Alors avec les écran haute résolution qui devraient finir par se démocratiser, Wayland plus efficace qu'X en distant?
Hum, j'ai un gros doute.
[^] # Re: 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é à 2.
Oui sur le redimensionnement des fenêtres Weston attend la fenêtre complète calculée par le client avant de l'afficher, donc si le client est lent ça peut saccader, ce qui sera bien pénible en effet!
Après je crois que KDE veut gérer la décoration des fenêtres coté serveurs d'affichage donc il est possible qu'ils gardent la technique actuelle 'fluide mais parfois moche' plutôt que 'parfait mais saccadé'.
Au moins pour déplacer les fenêtre Weston le fait tout seul donc ça devrait être fluide, c'est toujours ça!
[^] # Re: 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é à 2.
C'est une question intéressante..
Je sais que pour le Raspberry Pi ils ont utilisé l'accélération spécifique 2D de la carte à la place d'EGL, maintenant ça ne répond pas forcément à ta question je ne sais pas car je ne sais pas où ils ont utilisé l'accélération 2D: c'est peut-être uniquement dans le serveur et ta question est pour la communication client -> serveur d'affichage, le client peut-il préparer les buffers en utilisant de l'accélération 2D?
[^] # Re: 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é à 5.
Difficile à dire pour de bon tant que Wayland n'a pas un affichage distant fonctionnel ce qui permettrait de faire des vrais comparaisons, mais je pense que oui: avoir un mécanisme pour envoyer le texte séparément du fond permettrait de bien mieux traiter(compresser) chacun des 2 séparément (compression normal pour le fond et cache "à la XRender" pour les fontes) plutôt qu'une fois que tout a été mis dans un même buffer.
# 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"..