Une première chose, les deux textes que tu cite sont différents, l'un n'est pas la traduction de l'autre. (c'est juste pour que cela soi bien clair)
Ensuite, la citation du site est en effet plus nuancée, mais si tu regarde la liste qui est donnée juste après dans la page que tu donne, tu peux voir apparaître "latency hidding" et "threaded application". Or, nombreuse sont les application graphiques qui utilisent les threads, mais surtout les problèmes de latence sont commun à tous les programme qui utilisent la Xlib.
Bien sûr pour beaucoup cette latence est à peine perceptible, mais elle est toujours là. La faire disparaître contribuerait à rendre nos bureau plus réactifs.
Il faut aussi noter que même dans le pire des cas, en théorie XCB ne ralentit pas une application. (en theorie, puisque en pratique cela depend de la manière dont son codés chaques versions) En effet la Xlib envoie des requètes via le protocole X, éxactement ce que permet de faire XCB, mais d'une manière différente.
Mais dans la majoritée des cas la Xlib attend la réponse à la requète avant d'envoyer la suivante, là ou XCB te permet de traiter la reponse au moment ou tu en a rééllement besoin.
Un bon exemple est donné dans le tutoriel du wiki, il consiste à créer 500 atomes X. La version Xlib envoie une requète pour créer un atom attend la réponse et passe au suivant 500 fois de suite. La version XCB envoie 500 requète de création d'atom puis attend les réponses, donc pendant que les première requète et leurs réponses ce baladent sur le réseau, les suivantes sont envoyées.
Et même en local les performance sont meilleures, sur le PC de la personne qui à écrit le tutoriel la version XCB est environ 25 fois plus rapide. J'obtient à peu près le même ordre de grandeur sur le miens.
Bien sur cet exemple est un cas extrème et le boost de performance ne sera jamais aussi élevé, mais il y a quand même à gagner si les applications (et donc principalement les toolkit) sont migrés vers XCB.
Ce n'est pas pour rien que dans la plus parts des toolkit, il y a une utilisation des fameux roundtrips, la latence est un vrai problème que résoud XCB.
Bien sur tout n'est pas rose, notament XCB est plus bas niveau que la Xlib, et certaines choses simple à faire avec cette dernière deviennent tout de suite plus complexe. C'est pourquoi il y a aussi à écrire des bibliothèques de fonctions spécialisée et optimisée pour la XCB tout comme cela fut fait pour la Xlib.
PS: Je ne sais pas si tu as bien compris la phrase "ce qui accélérerait un maximum d'applications rapidement.". Le maximum fait référence au nombre d'application et le rapidement au temps nécéssaire pour obtenir ce gain de performance, il n'y a aucun ordre de grandeur donné. Le gain ne sera surement pas x10.
[^] # Re: Gros titres à sensations
Posté par beagf . En réponse à la dépêche Release Candidate 1 de XCB. Évalué à 10.
Ensuite, la citation du site est en effet plus nuancée, mais si tu regarde la liste qui est donnée juste après dans la page que tu donne, tu peux voir apparaître "latency hidding" et "threaded application". Or, nombreuse sont les application graphiques qui utilisent les threads, mais surtout les problèmes de latence sont commun à tous les programme qui utilisent la Xlib.
Bien sûr pour beaucoup cette latence est à peine perceptible, mais elle est toujours là. La faire disparaître contribuerait à rendre nos bureau plus réactifs.
Il faut aussi noter que même dans le pire des cas, en théorie XCB ne ralentit pas une application. (en theorie, puisque en pratique cela depend de la manière dont son codés chaques versions) En effet la Xlib envoie des requètes via le protocole X, éxactement ce que permet de faire XCB, mais d'une manière différente.
Mais dans la majoritée des cas la Xlib attend la réponse à la requète avant d'envoyer la suivante, là ou XCB te permet de traiter la reponse au moment ou tu en a rééllement besoin.
Un bon exemple est donné dans le tutoriel du wiki, il consiste à créer 500 atomes X. La version Xlib envoie une requète pour créer un atom attend la réponse et passe au suivant 500 fois de suite. La version XCB envoie 500 requète de création d'atom puis attend les réponses, donc pendant que les première requète et leurs réponses ce baladent sur le réseau, les suivantes sont envoyées.
Et même en local les performance sont meilleures, sur le PC de la personne qui à écrit le tutoriel la version XCB est environ 25 fois plus rapide. J'obtient à peu près le même ordre de grandeur sur le miens.
Bien sur cet exemple est un cas extrème et le boost de performance ne sera jamais aussi élevé, mais il y a quand même à gagner si les applications (et donc principalement les toolkit) sont migrés vers XCB.
Ce n'est pas pour rien que dans la plus parts des toolkit, il y a une utilisation des fameux roundtrips, la latence est un vrai problème que résoud XCB.
Bien sur tout n'est pas rose, notament XCB est plus bas niveau que la Xlib, et certaines choses simple à faire avec cette dernière deviennent tout de suite plus complexe. C'est pourquoi il y a aussi à écrire des bibliothèques de fonctions spécialisée et optimisée pour la XCB tout comme cela fut fait pour la Xlib.
PS: Je ne sais pas si tu as bien compris la phrase "ce qui accélérerait un maximum d'applications rapidement.". Le maximum fait référence au nombre d'application et le rapidement au temps nécéssaire pour obtenir ce gain de performance, il n'y a aucun ordre de grandeur donné. Le gain ne sera surement pas x10.