Journal XCB en version 1.0-RC1, le futur en marche...

Posté par  (site web personnel) .
Étiquettes : aucune
0
26
sept.
2006
Grande nouvelle... Bientôt la fin des trolls sur le fait que X est lent... En effet XCB est proche de la version 1.0, hier la version RC1 est sortie (désolé pour le retard mais j'ai pas mal de boulot en ce moment)

Tout d'abort, qu'est-ce que c'est ce truc ?
Tout le monde ici, je pense connait le système graphique X, puisqu'il équipe la très grosse majoritée des systèmes linux. Ce système est en fait un protocole qui permet à un serveur, le système d'affichage, de communiquer avec des clients, les applications. Les clients envoies des requettes 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 à 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ée soit localement via des socket unix, soit à distance via TCP.

Jusqu'à maintenant la gestion de ce protocole était principalement éffectuée par la Xlib. Elle fournies des fonctions haut-niveau qui sont transformées en série de requettes envoyée au serveur. Le problème de la Xlib est qu'elle est synchrone, c'est à dire (en simplifiant) qu'elle envoie une requette, attend la réponse du serveur, envoie la requette suivante... Hors le protocole X est fondamentalement asynchrone, c'est-à-dire que l'on envoie une série de requette et on traite les réponse quand elle arrivent. Le seul cas ou l'on doit attendre une réponse et donc bloquer le reste ce produit quand la reponse à une grande importance, ce qui arrive rarement dans une application graphique. En effet les applications graphiques ont tendance à être réactive plustôt que active.

C'est de ce problème qu'est né la légende que X est lent et que si on virait l'abstraction réseau on pourrait obtenir un système qui sux des mamans ours.

XCB est la pour contredire tout ces médisant 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 acces direct au protocole et permet de jouer directement avec les requètes. Il devient donc possible d'envoyer quelques tonnes de requettes sans attendre de réponses et quand l'appli 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 peu aussi servir de couche de transport pour la Xlib. Attention, ça veux pas dire que toutes les vieilles applis programmée avec les pieds vons soudain ce mettrent a être tellement rapide qu'elles en deviennent inutilisable, en effet mais en utilisant XCB la Xlib reste synchrone. L'avantage par contre est qu'il devient possible de mélanger les appels à la Xlib et à XCB et donc de migrer progressivement les applications.

Bon je m'enflamme mais déjà c'est juste une pré-version, mais la 1.0 ne devrait pas tardée puisque l'API est stabilisée et que si aucun problème dans cette API n'est soulevé durant cette phases de test la version 1.0 sortira d'ici peu. Le deuxième problème c'est que maintenant il va falloir ce motivé à porter les applications... et là il y a du boulot, mais c'est possible. Il existe déjà par exemble 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 max d'applis rapidement.

Donc maintenant au boulot...

Liens :
-------

Le site de XCB : http://xcb.freedesktop.org/
Vielle news LinuxFr : http://linuxfr.org/2004/08/13/17033.html
Encore plus vielle : http://linuxfr.org/2003/05/05/12270.html

Les téléchargements :
---------------------

http://xcb.freedesktop.org/dist/xcb-proto-0.9.91.tar.bz2
with sha1sum: b447894b8e46bc36dec89cf0ccd65e2db5e20b94

http://xcb.freedesktop.org/dist/xcb-proto-0.9.91.tar.gz
with sha1sum: b05f6f14d9266aa3827a444a2d77c453c1b3131d

http://xcb.freedesktop.org/dist/libxcb-0.9.91.tar.bz2
with sha1sum: 8da28b68107613b67dc0dc51dc06a361b11953b4

http://xcb.freedesktop.org/dist/libxcb-0.9.91.tar.gz
with sha1sum: edad8cb60daad429bc8ef0635ab2d6aeb6b6ae5d

La mailing-list :
-----------------

http://lists.freedesktop.org/mailman/listinfo/xcb

Annonce :
---------

Et pour finir une rapide traduction du début du mail de Jamey Sharp annoncant cette RC1.0 sur la mailling list du projet :

libxcb :

La libxcb est une interface au protocole X11, qui a pour but de remplacer l'actuelle interface de ce protocole : la Xlib. Elle à plusieurs avantages sur la Xlib :
- La taille : aussi bien la lib que l'empreinte memoire sont réduites.
- Masquage de la latence : il est possible (et même encouragé) d'envoyer une série de requettes sans attendre la réponse du serveur entre chacune.
- Acces direct au protocol : les fonctions proposées corresponde directement aux requettes du protocol.
- Gestion des thread : l'acces à XCB depuis plusieurs threads est transparent.
- Facilitée d'implémentation des extensions : Les interfaces sont générées depuis des fichiers XML décrivant le protocol.


xcb-proto :

xcb-proto contient la description du protocol au format XML que la libxcb utilise pour générer la majoritée 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 protocol 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 éfforts alors qu'avec XCB, le support ne nécéssite qu'une description XML de l'extention sans la moindre ligne de code.


Pourquoi cette release ?

Nous sortons cette pré-version pour permettre une plus grande vérification et test 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 aditions; les applications compilées avec XCB 1.0 ou plus fonctionerons avec toutes les futures versions de XCB. Saud découverte de problème sérieux avec l'API, nous ne prévoyons aucun changement de l'API entre cette release et la erlease 1.0.

Nous apprecierions annormément des relecture de l'API de cette release. Nous avons eu quelques retours sur le fait qu'imposer une verification statique des types des XID en C pose plus de problèmes que d'aide, donc nous apprécierions des commentaires sur ce point et sur le fait que cela puisse etre un serieux problème dans l'API. Il reste aussi quelques questions sur est-ceqque xcb_poll_for_event doit avoir le paramètre 'error' maintenant que XCB dispose d'un systeme de gestion des erreures plus uniforme.

XCB à été testé sur de nombreux OS, tels que GNU/Linux, FreeBSD, Solaris et MacOS. La plus part des test on été éffectués sur x86 et x86-64, mais les systèmes big-endian tel que PowerPC et SPARC on aussi un un peu testés. La bilibothèque doit compiler avec les versions récentes de GCC et du compilateur de Sun. Nous aimerions des tests sur des OS, procésseurs et compilateurs plus variés.

DISCLAIMER: Ce journal contient quelques notes d'humour povant être interprétées comme des attaques envers la Xlib et les programmes l'utilisant. J'ai un profond respect pour cette vénérable bibliothèque ainsi que ces programmes dépassés, qu'ils me pardonnent ;-)

  • # Pourquoi ?

    Posté par  . Évalué à -1.

    Manifestement, tu sais écrire "requête" à peu près correctement :

    jouer directement avec les requètes.


    Mais alors pourquoi, pourquoi tu écris huit fois "requette" ??

    • [^] # Re: Pourquoi ?

      Posté par  (site web personnel) . Évalué à 10.

      Je ne suis pas excusable pour autant de fautes, je le sais. Si je veux écrire un texte avec le moins de fautes possible, je dois me relire attentivement plusieurs fois, hors l'écriture de ce journal m'a déjà pris plus d'une heure (sans compter le temps que je vais passer à aller voir régulièrement les commentaires) et je ne peux pas y consacrer plus de temps.
      Dans ce cas pourquoi ne pas laisser quelqu'un d'autre écrire un journal de meilleur qualitée ? Tout simplement par ce que XCB est un projet assé discret, même si il est d'une grande importance pour le future de nos bureau. J'ai donc fait le choix d'un journal complet mais avec une plus faible qualitée orthographique, même si j'aurais préféré avoir le temps de le rendre encore mieux et d'en faire une dépèche.

      • [^] # Re: Pourquoi ?

        Posté par  . Évalué à 10.

        >Je ne suis pas excusable pour autant de fautes,

        Franchement, les fautes dans ce journal, je m'en fout. la qualité des informations fournies est vraiment impressionnante.

        Ce genre de projet est vraiment très très intéressant.

        A priori, vous recherchez des gens pour tester l'API., je ne pense pas avoir les compétences, mais en tout cas, je vais tenter la compil :-)

      • [^] # Re: Pourquoi ?

        Posté par  . Évalué à 9.

        Il est beau ton journal.

        Je ne l'echangerais pas contre un bon nombre de journal inutile, mais bien ecris.

      • [^] # Re: Pourquoi ?

        Posté par  (site web personnel) . Évalué à 2.

        Il manque 2 informations qui seraient rassurantes pour les testeurs :
        - comment se passe la cohabitation Xlib / XCB sur le système ? (on peut enlever XCB facilement ?). Notamment, préciser comment se lance le serveur X en utilisant XCB.
        - quelles applications sont déjà opérationnelles ? Je peux avoir un GNOME fonctionnel ? Quels environnements de bureau déjà et une liste d'applications qui tournent déjà serait un plus....

        Pour en profiter pleinement, je suppose qu'il faut recompiler les applis / modifier quelques appels d'API, un lien vers une page d'exemple ne serait pas inutile (à moins que l'abstraction Xlib/XCB soit réellement suffisante ?).

        En outre, quid du choix de XCB et Xlib dans le développement des applis (l'utilisation de Xlib/XCB semble être un pisse-aller : pour les développeurs, une option de compil' doit permettre de sélectionner une API ou l'autre, peut-être existe-t-il déjà une page traitant de ce sujet ?) http://xcb.freedesktop.org/wiki/XlibXcb me semble un peu court et un peu trop optimiste pour pousser les développeurs à se pencher réellement sur XCB (c'est un avis à chaud hein :p) : identifier les fonctionnalités qui manqueront permettrait de mettre en avant les avantages de l'API (et montrer de manière plus évidentes les évolutions disponibles).

        • [^] # Re: Pourquoi ?

          Posté par  (site web personnel) . Évalué à 3.

          hum je me réponds sur une partie par un RTFA... "L'idéal serait un portage d'un gros toolkit tel que GTK ce qui boosterait un maximum d'applis rapidement." bon GNOME à oublier pour l'instant, e17 ok...

          Sinon pour les autres questions ?

        • [^] # Re: Pourquoi ?

          Posté par  (site web personnel) . Évalué à 4.

          La cohabitation se passe très bien. Les deux lib parlent le même protocole avec le serveur, mais celui ci n'est pas "raciste" il accepte de parler aux deux. Tu peux donc installer XCB en parralèle sans problèmes, et utiliser en même temps des applis Xlib classique, des applis XCB pure, et des applis Xlib/XCB.

          Le lancement du serveur ne change absolument pas, XCB et Xlib sont utilisés uniquement par le client pour parler au serveur, le protocole étant le même dans tous les cas le serveur n'a même pas besoin d'être au courrant du changement.

          Pour les applis, en fait elles sont toutes opérationelle avec la version Xlib qui utilise XCB comme couche de transport. Pas mal de personnes utilisent déjà un système qui ne possède que XCB et cette version de la Xlib sans problème. Par contre ses application ne profitent que peut des avantages de XCB. Mais on peux éspérer une migration progressive de ces applications puisque il est possible de mélanger les appels Xlib et XCB au seins d'une même application.

          Il n'est pas nécéssaire de recompiler les applis si tu passe par la Xlib/XCB, par contre si tu veux passer à du XCB pure il est nécéssaire de modifier le code, parfois assez profondément pour pouvoir profiter notament de l'aspect asynchrone. Il y a aussi des différence assées importantes notament au niveau de la gestions des évenements.

          Pour ce qui est du choix entre les deux API, actuellement XCB se présente quand même comme l'avenir. Il est quasiment certains que cette API va s'imposer, mais la Xlib restera toujour présente à des fin de compatibilitée. Une fois la version 1.0 finale sortie, on verra probablement la Xlib standard remplacée par le couple XCB/Xlib.

          Le choix est donc entre les mains des développeurs, mais à mon avis, un developpeur qui bosse à ce niveau devrait serieusement envisager d'utiliser XCB. Ce qu'il faut bien voir, comme rappelé dans un commentaire plus bas, c'est que dans la majoritée des cas, les developpeurs bossent à un niveau plus élevé et utilisent des toolkit tel que GTK, il ne voient donc jamais les appels à la Xlib. La programation au niveau du protocole X est généralement limitée aux toolkit, au window manager, ou à des petites applications telle que les dockapps de window maker.

          Le principal objectif est donc de convertir ces systèmes d'abstraction pour que un maximum d'application bénéficies de XCB. Un gros boulot à déjà été fait pour evas, il me semble qu'il y a aussi eu du travail de fait pour cairo (mais je n'est pas trop suivi ça), une vieille version de GTK avait aussi étée portée mais le travail n'a pas été poursuivit. Bref, c'est possible, maintenant il va falloir du temps pour que ça ce fasse, mais il semble à peu près inévitable que l'on y viennent à l'avenir.

      • [^] # Re: Pourquoi ?

        Posté par  (site web personnel) . Évalué à 2.

        La solution: écris d'abord ton journal dans un logiciel possédant une correction orthographique (je rappelle que le nouveau dico d'OOo est disponible). Ensuite tu fais un simple copier coller. N'oublie pas qu'il y a des gens pour qui les fautes d'orthographe ne sont pas juste gênante, mais attirent plus l'attention que le propos en lui même.

        Hors ton journal est un des plus intéressants qu'il m'ait été donné de lire depuis un bon moment (pourquoi ne pas en avoir fait une dépêche d'ailleurs ?). Alors pour faire passer ton message, fais juste un petit effort sur la forme (qui ne devrait pas te prendre bien longtemps avec un correcteur), et tu augmenteras d'autant la popularité du projet: les gens ne se rappelleront pas juste qu'ils ont lu un journal écrit avec les pieds sur un truc du serveur X, mais qu'ils ont lu un journal sur xcb, une implémentation asynchrone du protocole X, et un successeur potentiel de la xlib.

        • [^] # Re: Pourquoi ?

          Posté par  (site web personnel) . Évalué à 3.

          http://wiki.eagle-usb.org/wakka.php?wiki=NewsXCB <-- la même sans fautes d'orthographes (mais avec quelques tournures à revoir et peut-être des points à ajouter sur la manière de faire les tests).

        • [^] # Re: Pourquoi ?

          Posté par  (site web personnel) . Évalué à 5.

          Hors ton journal
          Il est possible de passer directement par le navigateur pour corriger l'orthographe. Malheureusement, il n'est pas encore possible de corriger les fautes telles que celle que j'ai mise en gras (l'orthographe est bonne, mais le mot ne convient pas). Quant à la grammaire, j'ignore ce que valent les solutions existantes.
          Quand je veux vraiment éviter les fautes, je fais relire par quelqu'un d'autre.

          PS: c'est vrai que c'est journal privé fort instructif, bien fait, et les fautes ne m'ont pas géné (quand le fond est aussi complet, la forme passe, pour moi, au second plan)

          • [^] # Re: Pourquoi ?

            Posté par  (site web personnel) . Évalué à 1.

            Gloups :)
            Le pire c'est qu'en le lisant, c'est énorme, et si je l'écrivais à la main, je ne ferais pas la faute, mais l'utilisation d'un clavier a énormément fait baisser mon niveau en orthographe... :'-(

            J'avoue je ne me suis pas relu (je ne le fais quasiment jamais du reste).

            • [^] # Re: Pourquoi ?

              Posté par  . Évalué à 3.

              En fait, je crois que c'est le fait de lire les commentaires de linuxfr qui finit par faire faire des fautes. Je n'étais pas particulièrement sujet aux fautes d'orthographe par le passé, et j'ai fini par le devenir après être devenu un lecteur/commentateur assidu de ce site, au point que relire mes commentaires quelques heures/jours après les avoir postés me faisait honte.

              Finalement, je suis retourné passer mon temps sur Wikipédia, et mon orthographe s'en porte beaucoup mieux, même si l'on sent bien que mes cours de français sont loin derrière moi. :-)

              Simple coïncidence ? J'en doute : voir des fautes d'orthographe à longueur de journée, ça fini inconsciemment par faire douter, et on les fait à son tour sans même s'en rendre compte.

              • [^] # Re: Pourquoi ?

                Posté par  . Évalué à 2.

                Simple coïncidence ? J'en doute : voir des fautes d'orthographe à longueur de journée, ça fini inconsciemment par faire douter, et on les fait à son tour sans même s'en rendre compte.

                Tu veux dire comme mature, secure, service publique, disclaimer, encodage, scalable... ?

                ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

  • # ...

    Posté par  . Évalué à 8.

    cat $JOURNAL | ispell > /dev/depeche

  • # Dommage...

    Posté par  (site web personnel) . Évalué à 4.

    Pour une fois que je voulais faire un journal publique, je me plante avec la checkbox...

    Par contre, j'ai oublié de précisé que si quelqu'un veux faire une dépéche, qu'il n'hésite pas, comme je l'ai dit je n'ai pas suffisament de temps en ce moment pour la faire (peut-être pour la version 1.0) mais il serait dommage que cette nouvelle disparaise rapidement.

    • [^] # Re: Dommage...

      Posté par  (site web personnel) . Évalué à 3.

      faudra juste penser à reformuler le passage avec les mamans ours :)

      • [^] # Re: Dommage...

        Posté par  . Évalué à 2.

        on pourrait obtenir un système qui sux des mamans ours.


        on dit plutôt qui roxe non, surtout dans le contexte ?

        A part cela article très instructif ! Et ce projet semble très prometteur.
        Félicitations.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Dommage...

          Posté par  . Évalué à 1.

          Argh je viens de soumettre avec moults corrections et j'ai pas fait gaffe à ça :/

    • [^] # Re: Dommage...

      Posté par  . Évalué à 1.

      Je fais du nettoyage cosmétique à ton journal et je soumets

      • [^] # Re: Dommage...

        Posté par  (site web personnel) . Évalué à 2.

        hum il reste encore pas mal de fotes tout de même et ce journal permettrait d'approfondir quelques questions...

        Pourquoi ne pas utiliser un wiki pour amender le texte ? Pour ceux intéressés, je vous propose : http://wiki.eagle-usb.org/wakka.php?wiki=NewsXCB (cela permettra de corriger les dernières coquilles restantes).

        Je vois avec les autres modéros s'ils publieraient cette rc1 (il y a appel à tests qui peut permettre de le justifier). Y-a-t-il une roadmap de la release finale ? Et il faudrait ajouter des précisions sur l'utilisation du bugzilla et de la ML (en anglais) pour communiquer tout de même... voire une liste de tests à réaliser, plus détaillée que "essayez powerpc et sparc" (je caricature hein).

  • # À quand le support dans GTK+ ?

    Posté par  . Évalué à 5.

    La plupart des applications n'utilisent pas la Xlib directement, mais à travers des couches d'abstraction.

    Ces applications vont donc migrer automatiquement dès lors que leur couche d'abstraction sera portée pour utiliser XCB plutôt que Xlib.

    GTK+ est une telle abstraction.

    D'où la question qui titre ce message :-)

  • # Port de GTK trivial

    Posté par  . Évalué à 1.

    Si je ne m'abuse, GTK utilise maintenant uniquement Cairo comme backend.

    Mais Cairo dispose aussi d'un backend XCB.

    Fonc le port de GTK vers XCB va devenir trivial, non? Il suffirait de remplacer juste quelques x11_create_surface() par xcb_create_surface() dans GTK, et c'est parti....

    Est-ce que je dis une connerie?

    • [^] # Re: Port de GTK trivial

      Posté par  . Évalué à 4.

      oui

    • [^] # Re: Port de GTK trivial

      Posté par  (site web personnel) . Évalué à 2.

      Je ne suis pas sûr: certains appels cairo on été enlevés pour remettre les anciens appels GDK, pour des raisons de performance. Donc tous les appels n'utilisent pas directement cairo.

      • [^] # Re: Port de GTK trivial

        Posté par  . Évalué à 1.

        J'ai effectivement dit des conneries. Même si GTK utilise Cairo, y'a une grosse partie (dans GDK principalement) spéicifique à Xlib (environ 30.000 lignes avec commentaires).

        Le port n'est donc pas si trivial que ca.

Suivre le flux des commentaires

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