Projet initié en 2001 par Bart Massey, XCB approche de la version 1.0, hier la version candidate (RC1) est sortie.
Le système graphique X équipe la très grosse majorité des systèmes Linux ; c'est le protocole qui permet à un serveur d'affichage de communiquer avec des clients, les applications. Les clients envoient des requêtes d'affichage et le serveur affiche ce qui est demandé. Le protocole va plus loin, puisqu'il gère aussi les souris et les claviers, en bref tout ce qui constitue l'interface graphique de nos systèmes. Ce que ce système a d'intéressant, c'est qu'il permet de manière transparente l'affichage déporté, les requêtes du protocole pouvant être transférées soit localement via des sockets unix, soit à distance via TCP.
Jusqu'à maintenant la gestion de ce protocole était principalement effectuée par la Xlib. Elle fournit des fonctions haut-niveau qui sont transformées en série de requêtes envoyée au serveur. Le problème de la Xlib est qu'elle est synchrone, c'est à dire (en simplifiant) qu'elle envoie une requête, attend la réponse du serveur, envoie la requête suivante... Or le protocole X est fondamentalement asynchrone, c'est-à-dire que l'on envoie une série de requête et on traite les réponses quand elles arrivent. Le seul cas où l'on doit attendre une réponse et donc bloquer le reste se produit quand la réponse a une grande importance, ce qui arrive rarement dans une application graphique. En effet, les applications graphiques ont tendance à être réactives plutôt qu'actives.
C'est de ce problème qu'est née la légende que X est lent et que si on supprimait l'abstraction réseau on pourrait obtenir un système très efficace.
XCB est une nouvelle implémentation du protocole X mais asynchrone, elle met à disposition du programmeur un accès direct au protocole et permet de jouer directement avec les requêtes. Il devient donc possible d'envoyer quelques tonnes de requêtes sans attendre de réponse, et quand l'application dispose d'un peu de temps libre elle vérifie qu'il n'y a pas eu de gros problèmes.
Et comble du bonheur, XCB peut aussi servir de couche de transport pour la Xlib. Attention, ça ne veut pas dire que toutes les vieilles applications mal programmées vont soudain devenir tellement rapides qu'elles en seront inutilisables, car en utilisant XCB la Xlib reste synchrone. L'avantage est qu'il devient possible de mélanger les appels à la Xlib et à XCB et donc de migrer progressivement les applications.
La 1.0 ne devrait pas tarder puisque l'API est stabilisée. Si aucun problème dans cette API n'est soulevé durant cette phase de test la version 1.0 sortira d'ici peu. Le deuxième problème c'est que maintenant il va falloir se motiver pour porter les applications... et là il y a du travail, mais c'est possible. Il existe déjà par exemple une version XCB de evas la bibliothèque graphique de Enlightenment 17, et quelques autres. L'idéal serait un portage d'un gros
toolkit tel que GTK+, ce qui accélérerait un maximum d'applications rapidement.
NdM Cette dépêche est issue du journal de beagf.
