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
- Page principale de XCB sur freedesktop.org (4 clics)
- Note de Jamey Sharp sur XCB pour les développeurs (2 clics)
- La documentation de l'API (6 clics)
- La dépêche sur les souhait de Rasterman concernant XCB (7 clics)
- La liste de discussion XCB (1 clic)
- Le courriel d'avancement (1 clic)
# Performances ?
Posté par sherlokk . Évalué à 1.
[^] # Re: Performances ?
Posté par Philippe F (site web personnel) . Évalué à 10.
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 (site web personnel, Mastodon) . Évalué à 2.
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 . Évalué à 7.
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 . Évalué à 5.
ca n'a absolument rien a voir. tu confonds et melange les notions suivantes:
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 (site web personnel) . Évalué à 4.
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 . Évalué à 6.
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 Maxx . Évalué à -1.
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 . Évalué à 6.
[^] # Re: C'est donc ça ?
Posté par Yhar Gla . Évalué à 3.
D'après un sondage...
[^] # Re: C'est donc ça ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
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 Pierre Tramo (site web personnel) . Évalué à 2.
[^] # Re: C'est donc ça ?
Posté par Nap . Évalué à 3.
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 Yohann (site web personnel) . Évalué à 2.
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 tgl . Évalué à 3.
[^] # Re: C'est donc ça ?
Posté par Julien Portalier . Évalué à 1.
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 (site web personnel) . Évalué à 3.
[^] # Re: C'est donc ça ?
Posté par KiKouN . Évalué à 2.
[^] # Re: C'est donc ça ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # Re: C'est donc ça ?
Posté par Anonyme . Évalué à 2.
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 . Évalué à 2.
http://www.presence-pc.com/news/n4701.html(...)
[^] # Re: C'est donc ça ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 9.
ç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 Pierre Tramo (site web personnel) . Évalué à -1.
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 . Évalué à 1.
[^] # Re: C'est donc ça ?
Posté par Pierre Tramo (site web personnel) . Évalué à -1.
[^] # Re: C'est donc ça ?
Posté par wismerhill . Évalué à 3.
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 . Évalué à 1.
Beyond Good & evil, Spellforce, BattleField 1942, GTA ...
Enfin bon c'est vraiment HS.
[^] # Re: C'est donc ça ?
Posté par Pierre Tramonson . Évalué à -1.
Ce [Point Zorel] vous est décerné en toute bonne foi.
[^] # Re: C'est donc ça ?
Posté par tgl . Évalué à 6.
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 M . Évalué à 4.
[^] # Re: C'est donc ça ?
Posté par Anonyme . Évalué à 2.
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 (site web personnel) . Évalué à 4.
[^] # Re: C'est donc ça ?
Posté par Guillaume Knispel . Évalué à 3.
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 tgl . Évalué à 2.
[^] # Re: C'est donc ça ?
Posté par Olivier Jeannet . Évalué à 4.
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 . Évalué à 2.
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 Aldoo . Évalué à 10.
Quand est-ce que ça remplacera Xlib dans le projet x.org ? ;)
[^] # Re: Pont
Posté par Olivier Serve (site web personnel) . Évalué à -1.
[^] # Re: Pont
Posté par Jerome Herman . Évalué à 5.
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 F (site web personnel) . Évalué à 8.
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 . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 4.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 9.
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 F (site web personnel) . Évalué à 3.
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 . Évalué à 7.
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 skeespin (site web personnel) . Évalué à 7.
c'est bien ca ? ou suis je à coté de la plaque ?
[^] # Re: question
Posté par djrom . Évalué à 5.
[^] # Re: question
Posté par Philippe F (site web personnel) . Évalué à 4.
mv xlib.so /dev/null
ln -s xclib.so xlib.so
[^] # Re: question
Posté par Krunch (site web personnel) . Évalué à 9.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: question
Posté par Fred . Évalué à -1.
[^] # Re: question
Posté par Krunch (site web personnel) . Évalué à -1.
Hors sujet, moi ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Pourquoi un remplacement ?
Posté par Jllc . Évalué à 5.
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 . Évalué à 8.
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 Nap . Évalué à 6.
[^] # Re: Pourquoi un remplacement ?
Posté par Jllc . Évalué à 2.
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 . Évalué à 5.
# XCB+E17
Posté par _alex . Évalué à 5.
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 . Évalué à -1.
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 . Évalué à 10.
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 . Évalué à 0.
te ploussoierait tres volontiers, mais c tres obscur le fonctionnement de linuxfr.....
[^] # Du role des WM
Posté par djano . Évalué à 4.
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 . Évalué à 4.
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 . Évalué à 2.
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 . Évalué à 3.
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 djano . Évalué à 2.
Merci bien!
[^] # Re: XCB+E17
Posté par djano . Évalué à 2.
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 Simon TRENY . Évalué à 2.
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 Etienne Juliot (site web personnel) . Évalué à -3.
Euuuuh, je crois que le vendredi soir avant le week end, faut éviter de poster !! -> [-20]
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je n'ai pas bien compris
Posté par Philippe F (site web personnel) . Évalué à 10.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je n'ai pas bien compris
Posté par Damien Pobel (site web personnel) . Évalué à 2.
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 Cook Captain . Évalué à 4.
[^] # Re: Je n'ai pas bien compris
Posté par Mr_Moustache . Évalué à -2.
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.