dimanche 04 janvier
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Release Candidate 1 de XCB

Posté par Morreale Jean Roc (). Modéré le 26 septembre 2006.
0
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.

> Lire la suite (64 commentaires, moyenne: 3,2).   [dépêche : 2996 caractères]

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 :

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 publication ?

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 futurs modifications porterons 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 version et la 1.0.

Nous apprécierions énormément des relectures de l'API de cette version. 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 le besoin de xcb_poll_for_event d'avoir le paramètre 'error' alors que XCB dispose maintenant d'un système de gestion des erreurs plus uniforme.

XCB a été testé sur de nombreux systèmes, tels que GNU/Linux, FreeBSD, Solaris et MacOS. La plupart des tests on é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é. La bibliothèque doit compiler avec les versions récentes de GCC et du compilateur de Sun. Nous aimerions des tests sur des systèmes d'exploitation, processeurs et compilateurs plus variés.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Conjonction de coordination

Posté par pierthi () le 26/09/2006 à 14:07. (lien). Évalué à 1.

Puré, c'est le truc qu'on apprend au primaire. Comme je l'ai vu plus d'une fois cette erreur, je me permet d'extra-dimensionner le rectum de quelques drosophiles, en signalant qu'on ne dit pas "Hors le protocole X est ..." mais "Or le protocole X est".

Hors c'est plutôt pour signaler l'absence, genre "Hors de tout soupçon".

C.f www.ecole-primaire.org/^W http://fr.wikipedia.org/wiki/Conjonction_de_coordination

Sécurité ?

Posté par chimrod (Jabber id, page perso, ) le 26/09/2006 à 14:19. (lien). Évalué à 3.

Juste une petite question, est-ce que ça corrige la faille de sécurité qui menace X.org ? ( http://linuxfr.org/2006/05/15/20813.html ) ou bien le problème est-il également là ?

--
It is no bug, it's future

GTK, QT et les autres

Posté par gentildemon () le 26/09/2006 à 14:29. (lien). Évalué à 9.

Tout cela m'a l'air une excellente nouvelle de ce que je comprends.

Concernant le portage de gros toolkit tel que que GTK+, est-il déjà commencé/envisagé par l'équipe principale ?

Quant est-il pour QT ?

--
Vous avez la liberté de choisir, choisissez la liberté!

Gros titres à sensations

Posté par salvaire () le 26/09/2006 à 15:47. (lien). Évalué à 6.

Il est écrit à http://xcb.freedesktop.org/wiki/Features:

Xlib has been the standard C binding for the X Window System protocol for many years now. It is an excellent piece of work, but there are applications for which it is not ideal
devient sur linuxfr
La libxcb est une interface au protocole X11, qui a pour but de remplacer l'actuelle interface de ce protocole ... L'idéal serait un portage d'un gros toolkit tel que GTK+, ce qui accélérerait un maximum d'applications rapidement.


Moi j'ai compris qu'il y a des cas où la xlib n'est pas optimale. Que l'architecture client-serveur à un coût. Et que X est inutilisable sur un réseau sous-dimensionné. Un rapide survol de http://www.linuxshowcase.org/2001/full_papers/massey/massey.(...) ne me permet pas de conclure que XCB va accélérer dix fois GTK+ en non déporté. L'intérêt de XCB semble plus subtile que les gros titres à sensations.

Et les performances ?

Posté par nayco (page perso, ) le 26/09/2006 à 17:26. (lien). Évalué à 6.

Mais au fait, bien que cela n'a peut-être rien à voir, quid de l'occupation réseau engendrée par l'utilisation de XCB ?

J'avais lu, il y a plus d'un an, une explication concernant le fonctionnement de NX, pourquoi c'est plus rapide [1], etc...

Question : Est-ce que XCB allège le traffic réseau ? Sinon, et c'est presque hors-sujet, est-ce que X va intégrer les améliorations visiblement énormes de NX à ce niveau ? XCB peut-il enlarger mon serveur de terminaux ?



[1] On y parlait d'ailleur de drogues très en vogue dans le X, les "roundtrips".

--
Pan ! Pan !
Ne pas utiliser : traplinuxfrnico@univ-nantes.Fr

Quid de la XCL ?

Posté par Ontologia (page perso, ) le 27/09/2006 à 07:49. (lien). Évalué à 6.

Dixit wikipedia http://fr.wikipedia.org/wiki/XCB , la XCL est

une implémentation de l'API Xlib basée sur XCB, afin de fournir une couche de compatibilité aux applications basées sur la Xlib. Produite plus tard, la bibliothèque XLib/XCB fournit une ABI compatible aussi bien avec la Xlib qu'avec XCB, afin d'adoucir les difficultés de portage d'une bibliothèque à l'autre.


Je suppose donc qu'une fois cette librairie au point, testée, figée dans son ABI, on pourra mettre la Xlib aux oubliettes ?

petite question en passant ?

Posté par Rico () le 21/10/2006 à 01:41. (lien). Évalué à 1.

je débute avec les unix, mais j'aurrait une question en rapport avec ce poste.

y a-t-il un lien entre la XLib, et X.org ?
si oui, quel est-il ?
et aussi, est-ce que XCB, peut remplacer XLib dans cet usage ?

c'est peut etre pas clair, mais bon, je suis curieux alors je demande toujours

--
Knocking on Heaven's Door !

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.2421s (dont 0.0459 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !