Release Candidate 1 de XCB

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 clavier, bref tout ce qui constitue l'interface graphique de nos systèmes. Ce que ce système a de génial, 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êtes 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 supprimer l'abstraction réseau résoudrait ce problème.

XCB est là pour contredire tout ces médisants qui parlent sans connaître le problème ;-) En effet, 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 plusieurs requêtes sans attendre de réponse, puis quand l'application dispose d'un peu de temps libre, elle vérifie qu'il n'y a pas eu de gros problème.

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 programmées avec les pieds vont soudain devenir tellement rapides qu'elles en seront inutilisables, car même en utilisant XCB, la Xlib reste synchrone. L'avantage est qu'il devient possible de mélanger les appels à la Xlib et à XCB et ainsi de migrer progressivement les applications.

La 1.0 ne devrait pas tarder puisque l'API est stabilisée et que - si aucun problème dans cette API n'est soulevé durant cette phase de tests - la version 1.0 sortira d'ici peu. Le deuxième problème, c'est que maintenant il va falloir se motiver à porter les applications... et là, il y a du boulot, 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 boosterait un maximum d'applications rapidement.

Merci à beagf pour son <a href="journal">http://linuxfr.org/~beagf/22747.html">journal sur XCB</a>.

liens

Annonce de Jamey Sharp [en] http://lists.freedesktop.org/archives/xcb/2006-September/002050.html
Site de XCB [en] http://xcb.freedesktop.org/wiki/
Page de téléchargement [en] http://xcb.freedesktop.org/dist/
Ancienne dépêche linuxfr 2004 [fr] https://linuxfr.org/2004/08/13/17033.html
Page wikipedia sur XCB [en] http://en.wikipedia.org/wiki/XCB

corps de la dépêche

Traduction partielle de l'annonce de la RC1 par Jamey Sharp

"libxcb :

La libxcb est une interface au protocole X11, qui a pour but de remplacer l'actuelle interface de ce protocole : la Xlib. Elle a plusieurs avantages sur la Xlib :

• La taille : aussi bien la bibliothèque que son empreinte mémoire sont réduites.
• Masquage de la latence : il est possible (et même encouragé) d'envoyer une série de requêtes sans attendre la réponse du serveur entre chacune.
• Accès direct au protocole : les fonctions proposées correspondent directement aux requêtes du protocole.
• Gestion des threads : l'accès à XCB depuis plusieurs threads est transparent.
• Facilité d'implémentation des extensions : les interfaces sont générées depuis des fichiers XML décrivant le protocole.

xcb-proto :

xcb-proto contient la description du protocole au format XML que la libxcb utilise pour générer la majorité de son code et de son API. Elle est fournie séparément de la libxcb pour permettre une réutilisation simple par d'autres projets, tel que des interfaces à d'autres langages, des générateurs de documentations...

Cette séparation entre la couche de transport XCB et la couche protocole générée automatiquement rend aussi beaucoup plus facile la rédaction de nouvelles extensions. Avec l'infrastructure de la Xlib, le support côté client demande de gros efforts alors qu'avec XCB, le support ne nécessite qu'une description XML de l'extension, sans la moindre ligne de code.


Pourquoi cette release ?

Nous sortons cette pré-version pour permettre une plus grande vérification et plus de tests avant la version 1.0 de XCB. Lors de la version 1.0, la libxcb aura une API et une ABI stable ; les futures modifications porteront uniquement sur des ajouts ; les applications compilées avec XCB 1.0 (ou plus) fonctionneront avec toutes les futures versions de XCB. Sauf découverte de problèmes sérieux avec l'API, nous ne prévoyons aucun changement de l'API entre cette release et la release 1.0.

Nous apprécierions énormément des relectures de l'API de cette release. Nous avons eu quelques retours sur le fait qu'imposer une vérification statique des types des XID en C pose plus de problèmes qu'elle n'en résout, donc nous apprécierions des commentaires sur ce point et sur le fait que cela puisse être un sérieux problème dans l'API. Il reste aussi quelques questions sur est-ce que xcb_poll_for_event doit avoir le paramètre 'error' maintenant que XCB dispose d'un systeme de gestion des erreurs plus uniforme.

XCB a été testé sur de nombreux OS, tels que GNU/Linux, FreeBSD?, Solaris et MacOS. La plupart des tests ont été effectués sur x86 et x86-64, mais les systèmes big-endian tel que PowerPC? et SPARC ont été aussi un peu testés. La bibliothèque doit compiler avec les versions récentes de GCC et du compilateur de Sun. Nous aimerions des tests sur des OS, processeurs et compilateurs plus variés."

---