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é.
Vu les performances de XRender, je doutes qu'il y ait encore beaucoup de toolkit qui l'utilisent… A part xterm et probablement urxvt, il ne doit meme pas y avoir beaucoup de terminaux qui l'utilisent encore directement.
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!
Vu l'echec de l'API de dessin de Wayland, c'est une bonne chose que de ne pas mettre un truc inutile dedans et de completement le decoreller en se reposant entre autre chose sur OpenGL/EGL.
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..
Est-ce qu'il y a un seul toolkit qui utilise juste xcb ? La reponse est non pour une seule raison, il n'y a pas de support de XCB pour OpenGL de disponible avec la majorite des drivers (En fait, je ne sais meme pas si il y en a un qui le propose). Sur le papier xcb, c'est bien, mais au final, tu dois de toute facon avoir xlib, donc les toolkits se tappent une double stack qui n'apporte pas suffisament pour justifier l'effort.
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)!
J'avoue que j'ai du mal a comprendre cet objectif, si je veux juste du texte a distance, j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 9.
Vu les performances de XRender, je doutes qu'il y ait encore beaucoup de toolkit qui l'utilisent… A part xterm et probablement urxvt, il ne doit meme pas y avoir beaucoup de terminaux qui l'utilisent encore directement.
Vu l'echec de l'API de dessin de Wayland, c'est une bonne chose que de ne pas mettre un truc inutile dedans et de completement le decoreller en se reposant entre autre chose sur OpenGL/EGL.
Est-ce qu'il y a un seul toolkit qui utilise juste xcb ? La reponse est non pour une seule raison, il n'y a pas de support de XCB pour OpenGL de disponible avec la majorite des drivers (En fait, je ne sais meme pas si il y en a un qui le propose). Sur le papier xcb, c'est bien, mais au final, tu dois de toute facon avoir xlib, donc les toolkits se tappent une double stack qui n'apporte pas suffisament pour justifier l'effort.
J'avoue que j'ai du mal a comprendre cet objectif, si je veux juste du texte a distance, j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???