XCB : bientôt la version 1

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
13
août
2004
Serveurs d’affichage
XCB est un projet visant à créer une bibliothèque d'accès X Window plus bas niveau et surtout asynchrone pour faire alternative à la vénérable mais gourmande en performances XLib.

Un courriel de Jamey Sharp sur la liste XCB nous apprend que la bibliothèque a fait de gros progrès, et notamment le pont vers XLib qui est très proche de fonctionner parfaitement.
De plus l'API a été documentée (bien que certaines fonctions de la documentation ne soient présentes que dans le CVS). XCB est une bibliothèque dont le but est de se débarrasser des ralentissements provoqués par le système synchrone de la XLib. En effet avec la XLib lorsqu'un appel est fait au serveur X, l'ensemble de celui-ci est bloqué jusqu'à ce qu'il ait traité la requête. Or le protocole X est fait pour fonctionner en mode asynchrone, les requêtes au serveur ne devrait donc pas générer de blocage en mode exclusif du serveur. 90% des lenteurs imputés à X viennent en fait de la XLib.

Comme à toute étape charnière, le projet XCB a besoin de testeurs et de rapports de bugs. Ne vous laissez pas rebuter par l'installation qui peut être assez ardue (à faire de préférence depuis le CVS), Jamey Sharp et Bart Massey sont extrêmement réactifs et vous apporteront toute l'aide nécessaire pour mener à bien votre installation (par contre l'anglais est obligatoire). Le pont vers XLib nécessite aussi pas mal de tests, en théorie toute application compilée pour XLib devrait pouvoir fonctionner sous XCB en utilisant le pont.

En ce qui concerne la documentation elle est claire et agréable à lire, mais requiert un bon niveau de connaissance sur le protocole X11.
Ceux qui se sentent courageux peuvent s'essayer à porter des bibliothèques de XLib vers XCB natif (GTK, GTK+, QT, Imlib etc.)

Aller plus loin

  • # Performances ?

    Posté par  . Évalué à 1.

    Est-ce qu'ils ont un objectif pour les performances de cette librairie, comparativement à la XLib ?
    • [^] # Re: Performances ?

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

      D'apres ce que j'ai compris, leur objectif est plus en terme d'architecture. En revanche, ils sont convaincus, eux et tous les gourou de X, que ca va aller beaucoup plus vite puisqu'ils enlevent un certain nombre de blocages.

      Sinon, c'est vraiment une super nouvelle. Les gens vont pouvoir arreter de dire "remplacer X par le framebuffer parce que c'est trop lent" et passer en mode "remplacons Xlib par XCB" et tout sera plus beau sur nos ecrans.
      • [^] # Re: Performances ?

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

        Et il manquera plus que la gestion unifiée et smplifiée des polices.... parce que certaines distribs qui laissent encore Xfs alors qu'il y a la freetype... grah, c'est crispant.

        En tout cas, XCB était attendu depuis des années pour rivaliser avec la vietsse de rendu du moteur de Microsoft Windows (eh oui, il est rapide)
        • [^] # Re: Performances ?

          Posté par  . Évalué à 7.

          Et il manquera plus que la gestion unifiée et smplifiée des polices.... parce que certaines distribs qui laissent encore Xfs alors qu'il y a la freetype... grah, c'est crispant.

          Je vais peut être dire une connerie, mais xfs, c'est un serveur de polices, et freetype, une bibliothèque pour gérer un type de police en particulier. J'ai l'impression que les deux ne font pas la même chose, voir sont complémentaires.
        • [^] # gestion unifiee des fontes

          Posté par  . Évalué à 5.

          Et il manquera plus que la gestion unifiée et smplifiée des polices.... parce que certaines distribs qui laissent encore Xfs alors qu'il y a la freetype... grah, c'est crispant.

          ca n'a absolument rien a voir. tu confonds et melange les notions suivantes:
          • serveur de fonte (gestion de l'emplacement physique des fontes)
          • moteur de rendu
          • gestionnaire logique des fontes (liste de fontes par priorite selon la famille, ...)


          les distro sont deja passe a une gestion unifiee et simplifiee des fontes via fontconfig (modulo qq vieux programmes).

          xfs ne s'occupe que du stockage des fontes (permettant de deporter ledit stoquage sur un serveur distant)
    • [^] # Re: Performances ?

      Posté par  . Évalué à 6.

      Est-ce qu'ils ont un objectif pour les performances de cette librairie, comparativement à la XLib ?

      Pas vraiment, l'idée générale est que cela devrait être globalement très bénéfique.

      Je m'explique, si il y a une seule application sur le serveur X, alors le lock exclusif n'est pas vraiment génant, si elle est non threadée alors le lock est même plutot bénéfique en termes de perfs (pas besoin de mutexs, de vérifier les conditions de course etc.). Par contre dans a peu près tous les autres cas XCB devrait permettre au serveur X de s'occupper de plusieurs applications en même temps, pas besoin par exemple d'attendre d'avoir renvoyé l'intégralité d'un bitmap a une fenetre (fausse transparence entre autre) pour pouvoir afficher du texte dans une autre.

      Kha
  • # C'est donc ça ?

    Posté par  . Évalué à -1.

    90% des lenteurs imputés à X viennent en fait de la XLib.
    C'est donc ça le fameux goulot d'étranglement dont il était question il n'y pas si longtemps que ça dans un journal (ou dépêche, je ne me souviens plus).
    Donc finalement c'est une bonne nouvelle la bientôt version 1 de ce projet ? :)

    Bon en même temps je la ramène, mais j'y connais rien... :-/ --> [_]
    • [^] # Re: C'est donc ça ?

      Posté par  . Évalué à 6.

      90% des statistiques donn'ees sans preuves ne veulent rien dire..
      • [^] # Re: C'est donc ça ?

        Posté par  . Évalué à 3.

        Oui mais 80% des gens sont contre les sondages

        D'après un sondage...
        • [^] # Re: C'est donc ça ?

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

          Et 78,57% des statistiques sont fausses :-))

          C'est donc un gros chantier qui commence. De nombreux gros chantiers comme KDE, OpenOffice et dans une certaine mesure Gnome et même Linux sont maintenant en pleine maturité. Xlib devenant donc le point faible, ce chantier est opportun et logique.
    • [^] # Re: C'est donc ça ?

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

      C'est aussi les bugs des toolkits, les drivers pourri, la mauvaise utilisation...
      • [^] # Re: C'est donc ça ?

        Posté par  . Évalué à 3.

        justement, tiens quelle est la carte graphique permettant d'obtenir le meilleur de X-Window ?

        Par exemple, j'ai la possibilité de récupérer une Matrox Millénium G550, dont j'ai entendu dire qu'elle bénéficie d'un driver libre. Aurai-je de meilleurs résultats qu'avec une geForce2MX + driver proprio nVidia ?

        Merci et désolé pour ce gros HS

        tentative de rattrapage : avec une carte pas trop pourrie disposant d'un bon support sous X, on pourra bien évaluer les perfs, et justement s'affranchir du pb des drivers de mauvaise qualité
        • [^] # Re: C'est donc ça ?

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

          Ca depend ce que tu entends par 'prefs'

          En 3D, j'ai essayer les matrox sont nul, la moindre G-Force 1 l'atomise,
          En rapidite d'affichage 2D, j'ai rien vu de revolutionnaire.
          Reste la qualite d'affichage. Personnelement la encore j'ai ete decu, j'ai un Gros 22" en 2048x1536, un GForce 3 T200 affiche ca beaucoup plus proprement... Donc bon...


          Si tu la pas cher pour faire de la 2d sur un ecran pas trop grand...
          • [^] # Re: C'est donc ça ?

            Posté par  . Évalué à 3.

            Un avantage des matrox est qu'elles permettent de jouer avec directfb et ses effets bien sexy de façon confortable (et c'est ~ les seules). À part ça, effectivement, bof bof.
            • [^] # Re: C'est donc ça ?

              Posté par  . Évalué à 1.

              Faut pas oublié la fct° qui tue tout : le dualhead. Sur une seule carte le tout sur AGP. Pratique: deux sorties, hop deux écrans, le tout avec les accélérations qui vont bien. Bon certes il faut le binaire "hal" qui n'est pas libre pour faire fonctionner X correctement avec, mais bon.

              Mias il est vrai qu'en 3D ça commence à se faire vraiment très très vieux... idem pour la qualité en 2D, ces cartes commencent à se faire vieilles. Mais après il est dur de trouver des équivalents en dualhead :(
              • [^] # Re: C'est donc ça ?

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

                On parlait des nvidia au dessus, le dualhead marche tres bien avec le driver proprio sur une seule carte ou plusieurs (vive la sortie dvi et l'adaptateur vga qui va bien :) ... Et a priori, ati aussi. Donc bon, ta fonction qui tue tout, tout le monde peut plus ou moins l'avoir quelque soit la carte...
                • [^] # Re: C'est donc ça ?

                  Posté par  . Évalué à 2.

                  Oui, toutes les cartes modernes le font. Le plus de matrox, c'est plutôt le "trihead". Les cartes matrox sont souvent vendu avec un cable Y permettant de connecter jusqu'à 3 écran sur une seule cartes. Je ne sais pas si celà est exploitable sous linux toutefois.
                  • [^] # Re: C'est donc ça ?

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

                    Euh, d'apres ce que j'ai vu, ca c'est dispo avec la version proprio du driver matrox, pour les cartes genre parthelia, qui d'ailleurs ne fait pas de 3D il me semble...
            • [^] # Re: C'est donc ça ?

              Posté par  . Évalué à 2.

              ---À part ça, effectivement, bof bof.

              comment peut t on dire bof bof, avec la seule carte graphique 3D qui possède des drivers libres.

              DES DRIVERS LIBRES, c'est pourtant clair non? c'est cela son avantage, pas besoin de telecharger un driver sur internet. L'installation se fait sans souci, pas de problème avec acpi ou apm, voir des freezes inexpliqué, ou encore une incompatibilité quelquonque avec un chipset.

              -Ne pas attendre que nvidia propose de nouveau drivers, eh oui la majorité d'entre vous se jetent sur les nouveau drivers, qui sont plus mieux qui corrige plein de bug ou en ajoute.

              donc grace à matrox tu peux économiser du temps sur les forum d'aide, tu ne pourri pas ton noyau, et tu ne depends du bon vouloir d'un fournisseur de drivers.

              mais si t'es sous linux non pas par philosophie mais pour une autre raison, ben oui prend une Nvidia.

              ceci dit je peux jouer avec ma matrox g550, a enemy territory(640x400), quake 1 2 3, thinktanks, et tous les jeux opengl sous linux, sauf UT2004.
              • [^] # Re: C'est donc ça ?

                Posté par  . Évalué à 2.

                Je crois que t'as oublie Doom III et Unreal Engine 3 :)
                http://www.presence-pc.com/news/n4701.html(...)
              • [^] # Re: C'est donc ça ?

                Posté par  (site web personnel, Mastodon) . Évalué à 9.

                ET, quake3 et UT2004 sont PROPRIOS !!!!!

                ça pourri ton /usr/bin, tu peux pas les avoir sur le CD de ta distro, ils font souvent planter X, tu te rues sur le dernier patch qui corrige le tir du MegaBazooka(tm) en mode Solo.

                Grâce à frozen-bubble, tu peux économiser ton temps sur les forums des clans, tu ne pourris pas tes répertoires avec des binaires extérieurs à ta distro et surtout...
                ....
                ....
                tu restes logique avec la philosophie qui t'as fait choisir Linux et une matrox plutôt qu'une Xbox avec nvidia..
                ...



                (/me ne pouvait pas louper une mauvaise foi pareille :-) )

                Mes livres CC By-SA : https://ploum.net/livres.html

                • [^] # Re: C'est donc ça ?

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

                  ça pourri ton /usr/bin,

                  Raté, par défaut, c'est dans /usr/local

                  ils font souvent planter X

                  Je paries un demi carambar que tu n'as jamais essayé

                  Grâce à frozen-bubble, tu peux économiser ton temps sur les forums des clans

                  Normal, il n'y a que les linuxiens qui y jouent vu que c'est le seul jeu correct
                  • [^] # Re: C'est donc ça ?

                    Posté par  . Évalué à 1.

                    c vrai que c pas comme si on avait aussi tux racer ou powermanga hein
                    • [^] # Re: C'est donc ça ?

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

                      Oh, j'avais oublié ces merveilles qui ne sont que des clones de jeux existant il y a 10 ans.
                      • [^] # Re: C'est donc ça ?

                        Posté par  . Évalué à 3.

                        Comme pratiquement tous les jeux qui sortent dans le commerce pour le moment.
                        Vous avez vu comboen de jeux vraiment original (pas juste dans les détails) ces dernières années?
                        • [^] # Re: C'est donc ça ?

                          Posté par  . Évalué à 1.

                          Pas assez, jamais assez :)
                          Beyond Good & evil, Spellforce, BattleField 1942, GTA ...
                          Enfin bon c'est vraiment HS.
                • [^] # Re: C'est donc ça ?

                  Posté par  . Évalué à -1.

                  /me ne pouvait pas louper une mauvaise foi pareille

                  Ce [Point Zorel] vous est décerné en toute bonne foi.
              • [^] # Re: C'est donc ça ?

                Posté par  . Évalué à 6.

                > la seule carte graphique 3D qui possède des drivers libres.

                Enfin la seule avec les ATI quand même... (non, j'ai pas dis "toutes les ATI", mais quand même un gros paquets, et qui devrait croitre encore dans la prochaine release de X.org si j'en crois leur roadmap)
                • [^] # Re: C'est donc ça ?

                  Posté par  . Évalué à 4.

                  Ansi que les intel, via, ....
                  • [^] # Re: C'est donc ça ?

                    Posté par  . Évalué à 2.

                    certe mais matrox c'est le seul fabriquant ou leur driver linux c'est officielle, il ne s'en cache pas, donc dans leur section drivers il y a les sources pour linux.

                    http://www.matrox.com/mga/support/drivers/latest/home.cfm(...)

                    par ce que sur chez ati, tu peux te brosser pour avoir des sources d'un drivers. ce n'est que des binaires. eh oui petit scarabé la route vers les sources est longue et semé d'embuche.

                    sinon non je ne pourris pas mon /usr/bin :), mais uniquement mon /usr/local/bin/
                    • [^] # Re: C'est donc ça ?

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

                      Et comme dit plus haut, pour la parthelia, ca a bien changé: driver proprios et uniquement 2D... Si tu veux jouer a ce petit la donc, nvidia participe au driver open source nv (ca doit meme etre les seuls contributeurs maintenant, bien malin celui qui peut comprendre le driver)
                      • [^] # Re: C'est donc ça ?

                        Posté par  . Évalué à 3.

                        Ouai enfin participé au developpement d'un driver libre pour le rendre totalement incomprehensible à tous les autres developpeurs c'est pas forcement ce qu'il y a de plus glorieux.

                        Moi aussi je peux produire du code qui ressemble à de l'assembleur réécrit en C pour tous mes softs, comme ca après ca sera aussi obscure que des trucs proprio désassemblés :)

                        Faudrait penser à inscrire le driver nv à l'international obfuscation C code contest d'ailleurs :p
              • [^] # Re: C'est donc ça ?

                Posté par  . Évalué à 2.

                Et sinon, un peu off topic, mais c'est quoi ton pseudo sur ThinkTanks (enfin si t'en as un régulier) ?
        • [^] # Re: C'est donc ça ?

          Posté par  . Évalué à 4.

          Par exemple, j'ai la possibilité de récupérer une Matrox Millénium G550, dont j'ai entendu dire qu'elle bénéficie d'un driver libre.

          J'ai toujours une Matrox G400, ce que j'apprécie sur cette carte :
          - la grande propreté du signal (j'ai lu que les NVidia et autres ATI avaient tendances à avoir des circuits moins soignés)
          - les specs publiées, faisant de cette carte une des mieux supportées sous X11 (ou tout autre projet libre), que ce soit en 2D ou 3D.

          Il est vrai que je ne fais que de la 3D modérées donc les grosses perfs ne me manquent pas. Pour moi en 2D ça marche nickel.
        • [^] # Re: C'est donc ça ?

          Posté par  . Évalué à 2.

          une Matrox Millénium G550, dont j'ai entendu dire qu'elle bénéficie d'un driver libre.

          Dans mon message au-dessus, j'ai parlé de la G400, mais pour la G550 c'est bon aussi, je ne l'ai pas précisé explicitement (cf http://xfree.org/4.4.0/mga.4.html#toc3(...) pour l'info sur le support des cartes Matrox par XFree)
  • # Pont

    Posté par  . Évalué à 10.

    Est-ce que le gain en performance s'observera uniquement sur les applis programmées pour XCB, ou alors aussi sur celles, pour Xlib, qui utilisent XCB via le pont ?

    Quand est-ce que ça remplacera Xlib dans le projet x.org ? ;)
    • [^] # Re: Pont

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

      Quand ce sera prêt ?
    • [^] # Re: Pont

      Posté par  . Évalué à 5.

      Est-ce que le gain en performance s'observera uniquement sur les applis programmées pour XCB, ou alors aussi sur celles, pour Xlib, qui utilisent XCB via le pont ?

      sans être vraiment avantagées au niveau vitesse, les applications XLib utilisant le pont auront au moins la gentilesse de ne pas bloquer les autres. En d'autres termes utiliser le pont plutot que la librairie native permettra de garder le serveur X disponible pour faire autre chose, même quand une requête XLib sera en cours d'execution.

      Kha
      • [^] # Re: Pont

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

        J'ai l'impression qu'il y a un malentendu. De ce que j'ai compris, avec les problemes de latence la xlib ne font pas qu'une application bloque toutes les autres.

        Le principe, c'est qu'un appel xlib est bloquant. Donc pendant ce temps la, l'appli client appelante est bloquee. Pas de rafraichissement, du temps qu'elle pourrait utiliser a autre chose, etc. Avec XCB, cette meme appli n'est plus bloquee puisque les appels sont asynchrones. Elle peut faire autre chose en attendant le resultat.

        Je suis pas expert X donc dites-moi si j'ai rien compris. Si on suit mon raisonnement, utiliser le pont xlib ne devrait pas apporter tant que ca puisque pour des raisons de compabilites, les appels doivent etre bloquants aussi ? Bon, j'ai l'impression que je m'embrouille.
        • [^] # Re: Pont

          Posté par  . Évalué à 3.

          La Xlib dispose de plusieurs type d'appels. Certains fonctionnent en mode assynchrone, d'autres en mode synchorne mais sont bloquant pour l'appli et d'autres enfin sont bloquants pour l'ensemble du serveur.
          Le problème étant que les fonctions qui font appel aux propriétés de la fenêtre racine (profondeur de couleur, renvoit de segments bitmaps pour fausse transparence, positionnement automatique de la fenêtre au pixel de valeur absolue le quart de l'écran etc.) bloquent l'ensemble de la XLib qui va refuser toutes les autres demandes. Le serveur lui pendant ce temps là va se tourner les pouces.

          Comme les effets nécessitant des appels bloquant ssont de plus en plsu nombreux (bords de fenêtres arrondis, fond transparent ou translucide, lissage de polices, positionnement automatiques de fenêtres etc.) On imagine bien l'impact que celà finit par avoir.

          La plupart des applis essayent de mettr eun maximum d'information en cache pour éviter d'avoir a refaire un lookup gourmand, mais là c'est la mémoire qui prend et il y a aussi un ralentissement des perfs...

          Kha
        • [^] # Re: Pont

          Posté par  . Évalué à 2.

          Le principe, c'est qu'un appel xlib est bloquant. Donc pendant ce temps la, l'appli client appelante est bloquee. Pas de rafraichissement, du temps qu'elle pourrait utiliser a autre chose, etc. Avec XCB, cette meme appli n'est plus bloquee puisque les appels sont asynchrones. Elle peut faire autre chose en attendant le resultat.
          Et bien avec Xlib, le truc pas top, c'est que c'est le programmeur lui-meme qui doit gerer le multithreading pour pallier ce probleme. Alors que XCB etant asynchrone, je pense que la seule maniere de gerer ca correctement est de laisser la librairie gerer ca.

          Je suis pas expert X donc dites-moi si j'ai rien compris. Si on suit mon raisonnement, utiliser le pont xlib ne devrait pas apporter tant que ca puisque pour des raisons de compabilites, les appels doivent etre bloquants aussi ? Bon, j'ai l'impression que je m'embrouille.
          Plus ou moins. En fait, utiliser XCL permet de remplacer XLib par la meme interface (les signatures de fonctions sont identiques).
          L'avantage est que les programmes ecrits pour XLib peuvent continuer a marcher avec XCL sans les recompiler. Mais, je ne pense pas que l'on soit oblige de rendre ces appels "pseudo-bloquants". Cela doit marcher meme si l'on ne rend pas bloquants ces appels, sauf si l'application repose sur ce mecanisme de blocage pour une raison ou pour une autre (mais je ne vois pas laquelle).
          Les applications qui vont le mieux tirer parti de cette librairie seront forcement celles qui l'utiliseront en natif.
          • [^] # Re: Pont

            Posté par  . Évalué à 4.

            Et bien avec Xlib, le truc pas top, c'est que c'est le programmeur lui-meme qui doit gerer le multithreading pour pallier ce probleme. Alors que XCB etant asynchrone, je pense que la seule maniere de gerer ca correctement est de laisser la librairie gerer ca.

            En fait la XLib n'ets pas capable de gerer plusieurs instances de certains paramètres. Par exemple les propriétés d'une fenêtre ne peutvent exister qu'en un seul exemplaire, XGetWindowsProperties va donc entrainner un blocage de toutes les requètes qui ont besoin des propriétés d'une fenêtre ou des fenêtres racines. Celà implique que si on fait une requête sur la fenêtre racine, plus aucune requête de propriété sur les fenêtres ne peut avoir lieu. L'ensemble des applications est bel est bien bloqué jusqu'à ce que la XLib est finit de parser les propriétés et d'agir en conséquence.
            Par contre la mauvaise nouvelle est que sous XCB une grosse partie de la synchro et de la gestion des threads est encore faite a la main. Les cookies doivent être allouées et traités par le dev lui même.

            Plus ou moins. En fait, utiliser XCL permet de remplacer XLib par la meme interface (les signatures de fonctions sont identiques).

            En fait XCL n'existe plus vraiment, il s'agit désormais d'une version modifiée de la XLib pour laquelle XCB fait un peu effet de proxy. Il est ainsi possible de passer outre les problèmes vu plus haut.

            Kha
    • [^] # Re: Pont

      Posté par  . Évalué à 0.

      excusez le "je debarque d'une autre planete" mais :

      moi au debut je voyais XCB comme concurrent direct au travail de X.org/XFree. donc pas susceptible d'etre integrable a leur projet...
      la xlib ne representerait pas le plus gros du travail de Xorg/XFree ???
      ca n'a peut-etre pas de sens, mais vous estimez a quelle proportion l'importance de la xlib dans Xorg/XFree ???
      • [^] # Re: Pont

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

        > mais vous estimez a quelle proportion l'importance de la xlib dans Xorg/XFree ???

        heuuuu je dirais que Xlib représente moins de 5% du travail fait sur Xorg/XFree. EN fait plus personne ne touche à xlib depuis des années.
        La seule raison qui pousse à toucher à xlib à l'heure acyuel et de pouvoir le compiler de manière classique (./configure; make ; make install)

        Par contre, architecturalement, Xlib représente surement 30% de Xorg/XFree puisque c'est le passage obligatoire pour afficher des trucs à l'écran. les 70% restants étant les drivers et les autres technologie de X
        • [^] # Re: Pont

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

          Si j'ai bien compris, on a le schema suivant:

          Serveur d'affichage X <----[protocole X]---- xlib <--- client d'affichage X (Qt, Gtk, ...) <--- Application classique

          Donc la xlib serait une implementation cote client du protocole X. Le travail du cote de X.org portait surtout l'amelioration du serveur X. Xcb arrive en parfait complement.
          • [^] # Re: Pont

            Posté par  . Évalué à 7.

            Serveur d'affichage X <----[protocole X]---- xlib <--- client d'affichage X (Qt, Gtk, ...) <--- Application classique

            L'ordre est bon, mais il y a des erreurs.

            La Xlib fait partie du client, au même titre que les bibliothèques QT/Gtk/Motif/... Mais elle est plus bas niveau. Il y a des fonctions pour dessiner des points, des droites, des rectangles, créer de nouvelles fenêtres, etc ...

            Les bibliothèques graphiques QT/Gtk/... permettent en plus de faire des objets plus complexes. Par exemple dessiner un bouton (ce qui nécessite de faire un rectangle de fond, 4 trait de bordure extérieur, etc ...), des icônes standard.
  • # question

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

    XCL est donc une couche supplémentaire XCB qui permet de faciliter la migration de Xlib vers XCB ...
    c'est bien ca ? ou suis je à coté de la plaque ?
    • [^] # Re: question

      Posté par  . Évalué à 5.

      Yep, c'est tout à fait ça.
      • [^] # Re: question

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

        Comme c'est binary compatible, c'est facilite au point que tu peux faire:
        mv xlib.so /dev/null
        ln -s xclib.so xlib.so
        • [^] # Re: question

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

          Et quelques mois plus tard tu vas remarquer que ton /dev/null prend 3 Go sur le disque.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: question

            Posté par  . Évalué à -1.

            tu sort!
            • [^] # Re: question

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

              Surtout que si on utilise /dev/null avec un seul ">", le fichier ne risque pas de grossir en fait.

              Hors sujet, moi ?

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Pourquoi un remplacement ?

    Posté par  . Évalué à 5.

    D'après ce que je lis :
    Or le protocole X est fait pour fonctionner en mode asynchrone, [...]

    Si le protocole est fait pour, pourquoi la Xlib ne le fait pas directement ? Surtout que si on remlace la bibliothèque coté client, il faut logiquement un serveur ayant les mêmes fonctionnalités. La Xlib étant gérée par les mêmes développeurs que le XFree, le serveur a forcément les mêmes limitations.

    Ou alors, il est trop difficile de modifier la bibliothèque existante (et fonctionnement très bien) pour faire de l'asynchrone ?
    • [^] # Re: Pourquoi un remplacement ?

      Posté par  . Évalué à 8.

      Si le protocole est fait pour, pourquoi la Xlib ne le fait pas directement ?

      Les equivalents XLib des solutions propriétaires sont assynchrones. En ce qui concerne la XLib de XFree, je parlerais bien de l'attitude et des réponses faites par le projet XFree a mes demandes et à d'autres pour le passage de la XLib en mode assynchrone, mais on va encore me traiter de trolleur.

      Kha
      • [^] # Re: Pourquoi un remplacement ?

        Posté par  . Évalué à 6.

        aller vas-y, car même si c'était un troll, depuis quand les trolls sont indésirables sur DLFP ?
      • [^] # Re: Pourquoi un remplacement ?

        Posté par  . Évalué à 2.

        En ce qui concerne la XLib de XFree, je parlerais bien de l'attitude et des réponses faites par le projet XFree a mes demandes et à d'autres pour le passage de la XLib en mode assynchrone, mais on va encore me traiter de trolleur.

        Intéressant. Et avec Xorg, ça va bouger à ce niveau ? Parce que si oui, plus besoin de XCB (en supposant que le mode asynchrone soit le seul intérêt).
        • [^] # Re: Pourquoi un remplacement ?

          Posté par  . Évalué à 5.

          Ou alors, plutôt que réinventer la roue, on pourrait, comme je le suggérais tout à l'heure remplacer xlib par XCB au sein même du projet Xorg. En espèrant que les licences soient compatibles (mais a priori si la partie serveur et la partie client n'ont pas des licences compatibles, l'inconvénient n'est qu'esthétique).
  • # XCB+E17

    Posté par  . Évalué à 5.

    Le lien est peut être passé, mais bon :
    http://sourceforge.net/mailarchive/forum.php?thread_id=1945128&(...)

    C'est une discussion il y a un peu plus d'an sur l'intégration de XCB dans E17. Il y a plein de réponses aux questions qu'on peut se poser.
    • [^] # Re: XCB+E17

      Posté par  . Évalué à -1.

      je comprends vraiment rien, maintenant on compare une librairie X avec un gestionnaire de fenetres/bureau.
      en gros la lib, ils la mettent ou ils veulent, dans Xorg si on veut, dans le gestionnaire aussi ca passe !
      ca confusionne pas mal les choses !

      QCM, la lib :
      1) je la mets dans KDE, et toc !
      2) je la mets dans X.org
      3) je vire X.org et je les remplace, prout !
      • [^] # Re: XCB+E17

        Posté par  . Évalué à 10.

        La question tourne essentiellement de savoir si avoir E17 - qui est essentiellement un WM (window manager) fonctionnant directement sur XCB ne va pas poser problème avec les applications qui utilisent elles la Xlib. La question est légitime: est-ce que ça va pas tout casser nos belles applications sous X ?!

        Rasterman en profite pour expliquer quelle est la place d'un WM sous X mis en rapport avec les applications qu'il "manage". En expliquant q'un WM ne se pose pas entre le serveur X et les applications, mais que le serveur X est central et que le WM cause avec X tout comme le font les applications.

        Le problème ne se pose donc pas. Et ça se confirme si on y regarde d'un peu plus près. Car XCB - tout comme la Xlib - cause directement avec le protocole X11, donc directement avec le serveur XFree86. Au final XCB et Xlib font la même chose, mais de façon différente. XCB semblant d'ailleurs avoir une bien meilleure architecture générale que la Xlib. Et ça ne s'arrête pas qu'au mode asynchrone. Allez donc voir la page XCB sur freedesktop.org

        Résultat : il n'y a aucune raison pour qu'une applications utilisant la Xlib ait des problèmes à cause que le WM lui il utilise XCB. C'est là toute la base de la discussion sur la ML de e. Moi en tout cas ça m'a bien éclairé sur ce qu'est vraiment XCB. À noter que Rasterman est semble vraiment entousiasmé par cette nouvelle lib ^^

        Vala. L'explication est suffisamment claire ?

        Ha! Y'a aussi une ébauche de discussion sur l'intérêt réel de XCB, notamment mis en rapport avec Xorg (ou xouvert). Pas vraiment de réponse donné cependant. Mais à ce que j'ai cru comprendre XCB est bénéfique pour tout serveur X, car cette lib vient en remplacement ou se pose en concurrence de la Xlib. Je pense donc que XCB peut parfaitement être intégré à un autre serveur X. Surtout lorsque ceux-ci ont la même base : XFree86.

        Au final je pense que XCB devrait être bénéfique aussi à Xorg et xouvert. Miam d'avance ^^
        • [^] # Re: XCB+E17

          Posté par  . Évalué à 0.

          oui, tres interessant, merci ! j'avais commence a lire la discussion mais mon etat de fatigue m'empeche d'etre assez lucide pour capter de l'anglais aujourd'hui...........
          te ploussoierait tres volontiers, mais c tres obscur le fonctionnement de linuxfr.....
        • [^] # Du role des WM

          Posté par  . Évalué à 4.

          Rasterman en profite pour expliquer quelle est la place d'un WM sous X mis en rapport avec les applications qu'il "manage". En expliquant q'un WM ne se pose pas entre le serveur X et les applications, mais que le serveur X est central et que le WM cause avec X tout comme le font les applications.

          Justement parlons du role des WM. C'est pas tres clair.
          A quoi sert le WM?
          J'ai bien compris que c'etait un client X comme les autres, a ceci pres qu'il peut intercepter les evenements et les demandes de redimensionnement de fenetres, etc... sans se situer entre l'appli et le serveur X.

          Jusque la je crois que c'est ca. Mais alors quel est son role?
          J'ai compris qu'il raportait ces demandes a l'utilisateur? Comment? Pourquoi? Mystere.

          J'ai cru vaguement comprendre qu'il avait le "pouvoir" de decider de l'affichage d'une fenetre ou non (surement via une extension du protocole X). C ca? Est-ce que c'est comme ca qu'il parvient a gerer plusieurs fenetres, a les placer, a les redimensionner, etc... ?

          Merci de repondre a ces quelques interrogations.
          • [^] # Re: Du role des WM

            Posté par  . Évalué à 4.

            Justement parlons du role des WM. C'est pas tres clair.
            A quoi sert le WM?


            A mettre de l'ordre sur l'écran. Car d'un point de vue purement technique, on peut se passer de gestionnaire de fenêtres (c'est juste un peu inutilisable à partir de 2 fenêtres).

            Fait l'expérience. Lance un nouveau serveur X (qui sera le display :1, car je suppose que tu utilise déjà le display :0), et l'option "-ac" pour qu'il n'y ait plus de restriction d'accès :

            [jllc@Versa jllc]$ X :1 -ac

            Tu basculeras automatiquement dessus. Pour revenir à ton environnement de départ, utilise les touches Ctrl+Alt+F7, et Ctrl+Alt+F8 pour retourner au deuxième display.

            Lance quelques applications (légères pour le test) avec l'option "-display :1" pour qu'elles s'affichent sur le nouvel affichage sans gestionnaire de fenêtres :

            [jllc@Versa jllc]$ nedit -display :1

            (Faudrait peut être précisé des coordonnées différentes pour qu'elles ne se superposent pas : -geometry WIDTHxHEIGHT+XOFF+YOFF )

            Tes applications seront là, dans leurs petits rectangles, mais alors, plus de déco, plus aucun moyen de les déplacer, de les redimensionner, de faire passer l'une devant l'autre.

            Pour le "comment ça marche", je ne sais pas du tout comment inter-agissent X, le WM, et les applications.
            • [^] # Re: Du role des WM

              Posté par  . Évalué à 2.

              OK Merci!!

              En gros, le WM cree une sorte de grosse fenetre (que l'on pourrait appeler le bureau) dans laquelle il deplace plusieurs autres fenetres (les autres applis) selon les actions de l'utilisateur.

              C'est bien ca?

              Il doit donc bien avoir un moyen de recuperer les actions de l'utilisateur!! Mais lequel?
              • [^] # Re: Du role des WM

                Posté par  . Évalué à 3.

                En gros, le WM cree une sorte de grosse fenetre (que l'on pourrait appeler le bureau) dans laquelle il deplace plusieurs autres fenetres (les autres applis) selon les actions de l'utilisateur.

                A priori, ce que tu appelles la grosse fenêtre (la fenêtre racine je crois) existe indépendament du WM. La plupart des WM en contrôle la décoration (fond d'écran), parfois y ajoute des icônes, et en capte les évènements (pour créer un menu lors d'un clic sur le fond).

                Pour ce qui est des détails technique du fonctionnement du tout, ça dépasse largement mes connaissances.

                Il doit donc bien avoir un moyen de recuperer les actions de l'utilisateur!! Mais lequel?

                Toutes les interfaces graphiques marchent par programmation évenementielle. C'est à dire que c'est basé sur des évenements du clavier et de la souris (appuie de touche, clic et mouvement ...) que chaque application attend, et traite par une action particulière. Et pour les recevoir, chaque application doit dire au système (serveur X ici) qu'elle veut les recevoir.

                Si tu as fais le test en lançant XWindow sans WM, tu as du voir que chaque appli s'affchait dans son rectangle. Et bien chaque appli reçoit les évenements qui ont lieu à l'intérieur de ce rectangle, chez elle, puisque ça la concerne. Je suppose (car je n'ai pas étudié ça en particulier) que le WM demande à recevoir les évenment qui se produisent ailleurs que sur les applis. Entre autres sur les bords des applis où ils ont ajouté leur déco (barre de titre, ancre pour le redimensionnement ...).
                • [^] # Re: Du role des WM

                  Posté par  . Évalué à 2.

                  Ca commence a avoir du sens pour moi.

                  Merci bien!
      • [^] # Re: XCB+E17

        Posté par  . Évalué à 2.

        QCM, la lib :
        1) je la mets dans KDE, et toc !
        2) je la mets dans X.org
        3) je vire X.org et je les remplace, prout !


        Bizarre ce questionnaire!

        1) le lien entre la lib et KDE est le suivant:
        la lib est utilisee par Qt et Qt est utilisee par KDE. Donc par transitivité, la lib est utilisee par KDE

        2) le lien entre la lib et X.org est flou pour moi.
        Au fait, qui est le mainteneur de XLib?

        2) remplacer la Xlib c'est le but de XCB
        remplacer X.org, c'est pas le but de grand monde, a par ce qui veulent carrement supprimer le protocole X.


        Je sais pas si je reponds a tes questions vu que j'ai pas tout compris a ce que tu dis!!
  • # Compiler XCL...

    Posté par  . Évalué à 2.

    Quelqu'un a réussi à compiler XCL à partir du CVS?
    J'ai compiler XCB et les librairies nécessaires sans problèmes mais dans le répertoire xcb/xcl, il n'y a ni autogen, ni configure ni Makefile... donc je peux pas tester si les performances sont meilleures vu qu'il ne doit pas y avoir d'applications compatibles XCB (à part rxvt).
  • # Applications de XCB

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

    Ca voudrait aussi dire que Swing irait plus vite s'il était implémenté via un serveur Y lui utilisant XCB ??

    Euuuuh, je crois que le vendredi soir avant le week end, faut éviter de poster !! -> [-20]
  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Je n'ai pas bien compris

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

      Ca m'etonne qu'en lisant tout ca, tu n'aies pas compris.

      La texte que tu cites montre bien que X a une nautre asynchrone, mais que xlib a bufferiser les requetes pour en faire un truc synchrone. Resultat, il y a des appels de fonction bloquant qui empeche une application de gerer au mieux son rafraichissement. J'avais d'ailleurs discute avec Mathias Ettrich (fondateur de KDE, poste eleve chez Trolltech) qui expliquait qu'ils avaient passe pas mal de temps a traquer les appels les plus bloquants pour les remplacer par des appels moins bloquants.

      xlib agit comme une librairie qui parle le protocole X au serveur X. C'est donc une implmentation cote client du code necessaire pour gerer la communication avec le serveur.

      XCB est une autre implementation du protocole X. Elle parle le meme protocole donc peut discuter avec les memes serveurs. Cependant, son API n'est pas la meme. Tu feras sans doute un XCLOpenDisplay() puis un XCLWaitNextEvent(), etc. Les fonctionsn'ont peut etre pas le meme nom et ne fonctionnent pas de la meme maniere, bien qu'elles servent a la meme chose, parler le protocole X.

      La tu es triste et tu te dis que c'est dommage de devoir re-ecrire toutes les applications X-Window de la terre pour profiter de XCB.

      Mais les gentils concepteurs de XCB ont pense a toi: il y a XCL qui est le Xlib Compabilitiy Layer. C'est une lib qui contient exactement les memes fonctions que xlib, mais implementees en passant par XCB. En gros, tu as les memes .h mais les .c sont differents.

      C'est plus clair ?

      > Donc ma question, en quoi XCB va changer cela ?

      Les memes messages de protocoles seront envoyes au serveur, mais en utilisant une autre lib.

      > Je vais devoir laisser tomber ces appels Xlib pour autre chose ?
      Ca depend. Si tu utilise XCL, non. Si tu utilises uniquement XCB, oui, tu dois re-ecrire la partie graphique. Mais qui ecrit encore des applis en X aujourd'hui ? Les developpeurs de Qt, Gtk, Mozilla, GnuStep, Fox, etc vont se palucher la partie difficile du travail et le codeur d'appli moyen ne verra pas la difference.

      > Il ne faudra plus utiliser Xlib ?
      Non, plus de xlib. C'est le but.

      > XCB va dialoguer directement au serveur X sur la même machine sans passer par une couche réseau ?

      Il va bien dialoguer avec le meme serveur, en passant par la couche reseau, en utilisant le protocole X.

      > Comment rendre asynchrone un appel qui nécessite un résultat pour poursuivre le traitement sans ralentir le tout
      > et sans rajouter une complexité de traitement supplémentaire ?

      Le texte que tu cites donnes des elements de reponse. Le probleme de xlib, c'est pas tant que les appels soient synchrones, c'est qu'ils sont bufferises.

      Sinon, ca va se traduire en effet dans une approche un peu differente de la gestion des appels a la lib X. En effet, ca ristque d'etre costaud, mais optimiser l'utilisation de X par une appli, c'est par pour les petits joueurs. Il faut savoir quels appels sont couteux en temps, lesquels on peut economiser, quand faire quoi, reflechir si l'inversion de deux operations ne me permet pas de debloquer une operation suivante plus rapidement, etc. etc. C'est les experts de Qt, Gtk et tout ca qui vont faire le travail difficile et ca ne changera rien pour le developpeur KDE moyen, sauf que ce sera plus rapide a l'affichage.

      Note que de toute facon, la situation est encore pire pour l'instant. Pour optimiser des applis, les developpeurs de Qt sont obliges de comprendre exactement quels appels de xlib sont bufferises et de les eviter pour passer des appels plus rapides. A mon avis, XCB va leur simplifier grandement la vie.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Je n'ai pas bien compris

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

        > XCB va dialoguer directement au serveur X sur la même machine sans passer par une couche réseau ?

        Il va bien dialoguer avec le meme serveur, en passant par la couche reseau, en utilisant le protocole X.


        Le protocole X ne passe par le réseau que lorsque c'est nécessaire, sinon il utilise le segments de mémoire partagée, ça va beaucoup plus vite...

        https://damien.pobel.fr

        • [^] # Re: Je n'ai pas bien compris

          Posté par  . Évalué à 4.

          Uniquement, pour le transfert des pixmaps, et quand l'extension shm est activée. Sinon, X utilise les IPC pour le reste du protocole.
      • [^] # Re: Je n'ai pas bien compris

        Posté par  . Évalué à -2.

        J'avoue ne pas bien comprendre en quoi cela va améliorer grandement la réactivité de X.
        XCB est donc une nouvelle écriture du protocole X d'accord, mais en quoi celle-ci va être "révolutionnaire".
        De nouvelle gestion des priorités vont être définies?
        Le terme "synchrone" réapparait à tords et à travers dans le fil de cette discussion, mais la XLib est censée être synchrone à quel niveau? Je comprends qu'elle éxécute les ordre dans l'ordre de leur arrivée en bloquant donc certains appels qui pourrait être effectué en priorité par rapport à d'autres en attente)

        Bref, je trouve que cette news fait beaucoup de vagues, et que de nombreux surfeurs du dimanche s' essayent ;)

Suivre le flux des commentaires

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