Articles précédents : Développeur
- [23] JavaSearch : moteur de recherche dans la Javadoc
- [22] IronPython : implémentation pour Mono/.NET
- [15] Déclaration d'indépendance des développeurs
- [20] Cartes de références pour développeurs
- [5] Une version libre du Google File System
- [177] Mono 1.0 sous le feu des projecteurs
- [13] La Fondation Mozilla a un an
- [34] Un nouveau site à propos de la bibliothèque Qt.
- [30] Appel à contribution sur l'avenir de XUL
- [7] Un jeu concours
Liens connexes
- Page principale de XCB sur freedesktop.org (2182 hits)
- Note de Jamey Sharp sur XCB pour les développeurs (542 hits)
- La documentation de l'API (448 hits)
- La dépêche sur les souhait de Rasterman concernant XCB (1359 hits)
- La liste de discussion XCB (347 hits)
- Le courriel d'avancement (469 hits)
Dépêche modérée par
Dépêche éditée par
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).
![[en]](../../../images/en.png)
Page principale de XCB sur freedesktop.org (2182 hits)-
Note de Jamey Sharp sur XCB pour les développeurs (542 hits)
-
La documentation de l'API (448 hits)
![[fr]](../../../images/fr.png)
La dépêche sur les souhait de Rasterman concernant XCB (1359 hits)-
La liste de discussion XCB (347 hits)
-
Le courriel d'avancement (469 hits)
> Lire la suite (76 commentaires, moyenne: 3,7). [dépêche : 1282 caractères]
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.)
Performances ?
Est-ce qu'ils ont un objectif pour les performances de cette librairie, comparativement à la XLib ?
-
[^]Re: Performances ?
Posté par Philippe Fremy (page perso, ) le 13/08/2004 à 12:37. (lien). É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 Da Scritch (page perso, ) le 13/08/2004 à 17:02. (lien). É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 Jllc () le 13/08/2004 à 17:25. (lien). É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 Thierry Vignaud () le 13/08/2004 à 17:41. (lien). É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: gestion unifiee des fontes
Posté par Troy McClure (page perso, ) le 13/08/2004 à 19:50. (lien). Évalué à 4.> xfs ne s'occupe que du stockage des fontes
mais pas de façon compatible avec fontconfig, maintenant il ne sert plus à rien
http://www.mail-archive.com/fonts@xfree86.org/msg01950.html(...)
-
-
-
[^]Re: Performances ?
Posté par Jerome Herman () le 13/08/2004 à 13:20. (lien). É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 ?
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 reno () le 13/08/2004 à 12:46. (lien). Évalué à 6.90% des statistiques donn'ees sans preuves ne veulent rien dire..
-
[^]Re: C'est donc ça ?
Posté par Yhar Gla () le 13/08/2004 à 13:57. (lien). Évalué à 3.Oui mais 80% des gens sont contre les sondages
D'après un sondage...-
[^]Re: C'est donc ça ?
Posté par Pierre Jarillon (page perso, ) le 13/08/2004 à 23:36. (lien). É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 Stone Tramo () le 13/08/2004 à 13:00. (lien). Évalué à 2.C'est aussi les bugs des toolkits, les drivers pourri, la mauvaise utilisation...
-
[^]Re: C'est donc ça ?
Posté par Nap () le 13/08/2004 à 13:11. (lien). É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 Silence (page perso, ) le 13/08/2004 à 13:47. (lien). É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...--
^d^c-
[^]Re: C'est donc ça ?
Posté par tgl () le 13/08/2004 à 14:15. (lien). É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 Julien Portalier (page perso, ) le 13/08/2004 à 15:06. (lien). É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 Mathieu Pillard (page perso, ) le 13/08/2004 à 15:39. (lien). É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 KiKouN (Jabber id, ) le 13/08/2004 à 17:06. (lien). É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.
--
KiKouN, Bucheron-Geek-
[^]Re: C'est donc ça ?
Posté par Mathieu Pillard (page perso, ) le 13/08/2004 à 19:29. (lien). É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 dark_star () le 13/08/2004 à 15:54. (lien). É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 Sebastien Binet () le 13/08/2004 à 15:59. (lien). É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 ploum (page perso, ) le 13/08/2004 à 16:55. (lien). É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 :-) )-
[+] [^]Re: C'est donc ça ?
Posté par Stone Tramo () le 13/08/2004 à 17:12. (lien). É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 PenPen () le 13/08/2004 à 18:53. (lien). Évalué à 1.c vrai que c pas comme si on avait aussi tux racer ou powermanga hein
-
[+] [^]Re: C'est donc ça ?
Posté par Stone Tramo () le 13/08/2004 à 18:59. (lien). É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 wismerhill (page perso, ) le 14/08/2004 à 11:12. (lien). É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 Pierre Tramonson () le 14/08/2004 à 11:57. (lien). É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 Pierre Tramonson () le 13/08/2004 à 17:33. (lien). É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 tgl () le 13/08/2004 à 17:20. (lien). É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 ?
-
[^]Re: C'est donc ça ?
Posté par dark_star () le 14/08/2004 à 09:52. (lien). É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 Mathieu Pillard (page perso, ) le 14/08/2004 à 11:21. (lien). É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 Guillaume Knispel () le 18/08/2004 à 02:34. (lien). É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 ?
-
-
-
-
[^]Re: C'est donc ça ?
Posté par Olivier Jeannet () le 13/08/2004 à 15:43. (lien). É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 Olivier Jeannet () le 13/08/2004 à 17:07. (lien). É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
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 Olivier Serve (Jabber id, page perso, ) le 13/08/2004 à 13:02. (lien). Évalué à -1.Quand ce sera prêt ?
-
[^]Re: Pont
Posté par Jerome Herman () le 13/08/2004 à 13:23. (lien). É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 Philippe Fremy (page perso, ) le 13/08/2004 à 16:39. (lien). É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 Jerome Herman () le 16/08/2004 à 07:46. (lien). É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 djano () le 16/08/2004 à 07:50. (lien). É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 Jerome Herman () le 16/08/2004 à 11:34. (lien). É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 skasowac () le 13/08/2004 à 14:35. (lien). É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 Christophe Merlet (page perso, ) le 13/08/2004 à 14:55. (lien). É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 Philippe Fremy (page perso, ) le 13/08/2004 à 16:44. (lien). É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 Jllc () le 13/08/2004 à 17:30. (lien). É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
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
-
[^]Re: question
Posté par Philippe Fremy (page perso, ) le 13/08/2004 à 16:45. (lien). É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 Krunch (Jabber id, page perso, ) le 13/08/2004 à 21:41. (lien). Évalué à 9.Et quelques mois plus tard tu vas remarquer que ton /dev/null prend 3 Go sur le disque.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[+] [^]Re: question
-
[+] [^]Re: question
Posté par Krunch (Jabber id, page perso, ) le 14/08/2004 à 00:37. (lien). Évalué à -1.Surtout que si on utilise /dev/null avec un seul ">", le fichier ne risque pas de grossir en fait.
Hors sujet, moi ?--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
-
Pourquoi un remplacement ?
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 Jerome Herman () le 13/08/2004 à 13:30. (lien). É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 ?
-
[^]Re: Pourquoi un remplacement ?
Posté par Jllc () le 13/08/2004 à 14:02. (lien). É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 Aldoo (Jabber id, ) le 13/08/2004 à 15:51. (lien). É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
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 skasowac () le 13/08/2004 à 15:02. (lien). É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 Julien Portalier (page perso, ) le 13/08/2004 à 15:23. (lien). Évalué à 19.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 skasowac () le 13/08/2004 à 15:31. (lien). É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 djano () le 13/08/2004 à 15:51. (lien). É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 Jllc () le 13/08/2004 à 17:46. (lien). É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 djano () le 16/08/2004 à 08:00. (lien). É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 Jllc () le 16/08/2004 à 09:55. (lien). É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
-
-
-
-
-
-
[^]Re: XCB+E17
Posté par djano () le 13/08/2004 à 15:34. (lien). É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...
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
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]
Je n'ai pas bien compris
D'après le manuel officiel de Xlib, je cite : « Most of the functions in Xlib just add requests to an output buffer. These requests later execute asynchronously on the X server. Functions that return values of information stored in the server do not return (that is, they block) until an explicit reply is received or an error occurs. You can provide an error handler, which will be called when the error is reported. » Comparé à cette nouvelle, je crois qu'il y a un malentendu quelque part sur la nature "synchrone" de X présenté comme systématiquement synchrone et bloquante.
Par ailleurs, je n'ai pas compris ce qu'est XCB techniquement: j'ai lu et relu les liens, j'ai lu les commentaires mais appremment il y a beaucoup de confusion et bien que tout le monde a "compris" que ce sera plus rapide, personne ne semble savoir ce que c'est exactement.
Concrètement, j'écrit un programme X avec Xlib : j'ouvre mon display avec XOpenDisplay(), je crée un fenêtre avec XCreateWindow(), je dessis dedans avec les fonctions X standard et je traite les événements avec XNextEvent() en attendant de terminer mon programme et de clôturer ma connection au serveur X. le tout avec Xlib qui se charge d'interfacer mes appels et de les faire suivre vers le serveur.
Donc ma question, en quoi XCB va changer cela ? Je vais devoir laisser tomber ces appels Xlib pour autre chose ? Il ne faudra plus utiliser Xlib ? XCB va dialoguer directement au serveur X sur la même machine sans passer par une couche réseau ? 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 ?
Si quelqu'un a des réponses autre que "ça va révolutionner le monde car c'est plus rapide", je suis preneur parce que là, c'est assez flou. Je ne vois pas en tant que développeur où s'intercale XCB ou ce que remplace XCB ou comment fonctionne XCB. Et que la personne qui a la réponse ne soit pas avare en détail technique, que ce soit sur le protocole X ou sur des détails d'implémentation de XCB, j'aime ça :)
-
[^]Re: Je n'ai pas bien compris
Posté par Philippe Fremy (page perso, ) le 13/08/2004 à 18:00. (lien). Évalué à 20.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.-
[^]Re: Je n'ai pas bien compris
Posté par L () le 13/08/2004 à 18:10. (lien). Évalué à 3.Ok, j'ai compris. Tu m'aurais dit que c'est une autre implémentation de Xlib avec sa propre API ainsi qu'une couche de compatibilité niveau API (XCL) pour les clients X utilisants les appels Xlib que ça aurait suffit en fait :) Je te remercie pour ces explications qui ont enfin le mérite de lever le voile sur toute cette confusion.
-
[^]Re: Je n'ai pas bien compris
Posté par Damien POBEL (page perso, ) le 13/08/2004 à 19:57. (lien). É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...-
[^]Re: Je n'ai pas bien compris
Posté par Cook Captain () le 13/08/2004 à 20:25. (lien). É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 mr_moustache () le 14/08/2004 à 21:25. (lien). É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 ;)
-
Cette page a été générée par Templeet en 0.2574s (dont 0.0272 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.