Le système graphique X équipe la très grosse majorité des systèmes Linux ; c'est le protocole qui permet à un serveur d'affichage de communiquer avec des clients, les applications. Les clients envoient des requêtes d'affichage et le serveur affiche ce qui est demandé. Le protocole va plus loin, puisqu'il gère aussi les souris et les claviers, en bref tout ce qui constitue l'interface graphique de nos systèmes. Ce que ce système a d'intéressant, c'est qu'il permet de manière transparente l'affichage déporté, les requêtes du protocole pouvant être transférées soit localement via des sockets unix, soit à distance via TCP.
Jusqu'à maintenant la gestion de ce protocole était principalement effectuée par la Xlib. Elle fournit des fonctions haut-niveau qui sont transformées en série de requêtes envoyée au serveur. Le problème de la Xlib est qu'elle est synchrone, c'est à dire (en simplifiant) qu'elle envoie une requête, attend la réponse du serveur, envoie la requête suivante... Or le protocole X est fondamentalement asynchrone, c'est-à-dire que l'on envoie une série de requête et on traite les réponses quand elles arrivent. Le seul cas où l'on doit attendre une réponse et donc bloquer le reste se produit quand la réponse a une grande importance, ce qui arrive rarement dans une application graphique. En effet, les applications graphiques ont tendance à être réactives plutôt qu'actives.
C'est de ce problème qu'est née la légende que X est lent et que si on supprimait l'abstraction réseau on pourrait obtenir un système très efficace.
XCB est une nouvelle implémentation du protocole X mais asynchrone, elle met à disposition du programmeur un accès direct au protocole et permet de jouer directement avec les requêtes. Il devient donc possible d'envoyer quelques tonnes de requêtes sans attendre de réponse, et quand l'application dispose d'un peu de temps libre elle vérifie qu'il n'y a pas eu de gros problèmes.
Et comble du bonheur, XCB peut aussi servir de couche de transport pour la Xlib. Attention, ça ne veut pas dire que toutes les vieilles applications mal programmées vont soudain devenir tellement rapides qu'elles en seront inutilisables, car en utilisant XCB la Xlib reste synchrone. L'avantage est qu'il devient possible de mélanger les appels à la Xlib et à XCB et donc de migrer progressivement les applications.
La 1.0 ne devrait pas tarder puisque l'API est stabilisée. Si aucun problème dans cette API n'est soulevé durant cette phase de test la version 1.0 sortira d'ici peu. Le deuxième problème c'est que maintenant il va falloir se motiver pour porter les applications... et là il y a du travail, mais c'est possible. Il existe déjà par exemple une version XCB de evas la bibliothèque graphique de Enlightenment 17, et quelques autres. L'idéal serait un portage d'un gros toolkit tel que GTK+, ce qui accélérerait un maximum d'applications rapidement.
NdM Cette dépêche est issue du journal de beagf. Traduction partielle de l'annonce de la RC1 par Jamey Sharp :
libxcb
La libxcb est une interface au protocole X11, qui a pour but de remplacer l'actuelle interface de ce protocole : la Xlib. Elle a plusieurs avantages sur la Xlib :
- La taille : aussi bien la lib que l'empreinte mémoire sont réduites.
- Masquage de la latence : il est possible (et même encouragé) d'envoyer une série de requêtes sans attendre la réponse du serveur entre chacune.
- Accès direct au protocole : les fonctions proposées correspondent directement aux requêtes du protocole.
- Gestion des threads : l'accès à XCB depuis plusieurs threads est transparent.
- Facilité d'implémentation des extensions : Les interfaces sont générées depuis des fichiers XML décrivant le protocole.
xcb-proto
xcb-proto contient la description du protocole au format XML que la libxcb utilise pour générer la majorité de son code et de son API. Elle est fournie séparément de la libxcb pour permettre une réutilisation simple par d'autres projets, tel que des interfaces à d'autres langages, des générateurs de documentations...
Cette séparation entre la couche de transport XCB et la couche protocole générée automatiquement rend aussi beaucoup plus facile la rédaction de nouvelles extensions. Avec l'infrastructure de la Xlib, le support côté client demande de gros efforts alors qu'avec XCB, le support ne nécessite qu'une description XML de l'extension sans la moindre ligne de code.
Pourquoi cette publication ?
Nous sortons cette pré-version pour permettre une plus grande vérification et plus de tests avant la version 1.0 de XCB. Lors de la version 1.0, la libxcb aura une API et une ABI stable; les futurs modifications porterons uniquement sur des ajouts; les applications compilées avec XCB 1.0 ou plus fonctionneront avec toutes les futures versions de XCB. Sauf découverte de problèmes sérieux avec l'API, nous ne prévoyons aucun changement de l'API entre cette version et la 1.0.
Nous apprécierions énormément des relectures de l'API de cette version. Nous avons eu quelques retours sur le fait qu'imposer une vérification statique des types des XID en C pose plus de problèmes qu'elle n'en résout, donc nous apprécierions des commentaires sur ce point et sur le fait que cela puisse être un sérieux problème dans l'API. Il reste aussi quelques questions sur le besoin de xcb_poll_for_event d'avoir le paramètre 'error' alors que XCB dispose maintenant d'un système de gestion des erreurs plus uniforme.
XCB a été testé sur de nombreux systèmes, tels que GNU/Linux, FreeBSD, Solaris et MacOS. La plupart des tests on été effectués sur x86 et x86-64, mais les systèmes big-endian tel que PowerPC et SPARC ont été aussi un peu testé. La bibliothèque doit compiler avec les versions récentes de GCC et du compilateur de Sun. Nous aimerions des tests sur des systèmes d'exploitation, processeurs et compilateurs plus variés.
Aller plus loin
- Annonce de Jamey Sharp (1 clic)
- XCB (7 clics)
- Téléchargement (1 clic)
- Dépêche précédente sur LinuxFr (2 clics)
- Journal de beagf (1 clic)
- XCB sur Wikipedia (5 clics)
# Conjonction de coordination
Posté par pierthi . Évalué à 1.
Hors c'est plutôt pour signaler l'absence, genre "Hors de tout soupçon".
C.f www.ecole-primaire.org/^W http://fr.wikipedia.org/wiki/Conjonction_de_coordination
[^] # Re: Conjonction de coordination
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Conjonction de coordination
Posté par Yth (Mastodon) . Évalué à 10.
C'est juste un langage de plus à connaitre, utilisant des protocoles ouverts, et aux spécifications publiques et libres.
for(x=0){
printef("zero !")
eles if(x==1)
printef("un !")
}
Hein ?
T'es pas rendu à essayer de coder en C en langage SMS tiens :
f x=0
pf(0) ls x=1
pf(1
)
Heureusement que les interpréteurs de français les plus communément utilisés (ça traine dans le cerveau, ça peut fonctionner en l'absence de ce dernier, en version bridée) ont une capacité d'adaptation et d'interprétation époustouflante en comparaison des meilleurs compilateurs de langage informatique !
Yth.
[^] # Re: Conjonction de coordination
Posté par salvaire . Évalué à 1.
1) Les langues vivantes, et l'évolution des langues indo-européennes.
2) Les grammaires -non- contextuelles
Bon travail
[^] # Re: Conjonction de coordination
Posté par erik_lallemand . Évalué à 7.
A mon avis, tu n'as pas du visiter d'écoles d'ingénieurs en informatique récemment. Le niveau de maîtrise de la langue française y est déplorable. Un petit exemple concret : lors de ma 1ère année de cycle ingénieur, le responsable de la communication ayant constaté les lacunes linguistiques de ses élèves (nous, quoi!) nous a soumis à une dictée d'une 20aine de lignes (pour une écriture moyenne). Le niveau de langue était courant et le vocabulaire était connu. Pas de piège de grammaire. Résultat : une moyenne de 20 fautes par copie.
Conclusion : les spécifications de la langue française sont publiques et plus ou moins libres, mais la langue des informaticiens a forké fourché.
[^] # Re: Conjonction de coordination
Posté par Anonyme . Évalué à -3.
Faut dire que la comm' c'était un coefficient misérable, et que ça permettait surtout de décompresser des cours de maths / physique (ben ouais, les cours d'info, c'était rare en fait).
[^] # Re: Conjonction de coordination
Posté par Sebastien . Évalué à -1.
(j'en connais).
[^] # Re: Conjonction de coordination
Posté par mickaël rameau . Évalué à -9.
aller au post 50 pour lire du XCB ....
Les intégristes de la politique et de la grammaire aller ailleur ici ---->[]
Linux = le PC, le systéme , on est pas au dico d'or et si vous aimez tant que çà
l'ortographe faite diodocfr.org ...
Les informaticiens parle l'anglais, je suis pour l'abandon simple du français
90 % de la planéte parle anglais.
Comparer le C au Français arrête ton fanatisme ...
On parle en SMS because c'est court, simple, universel, création d'un nouveau
langage ...
[^] # Re: Conjonction de coordination
Posté par Yth (Mastodon) . Évalué à 8.
Tiens, lis ça, ça m'évitera de trop me répéter.
Par ailleurs l'anglais n'est parlé que par un peu moins de 8% des gens... On est très très loin des 90% même si cette langue arrive en deuxième position derrière le Mandarin plus de deux fois plus parlé (un peu plus de 16%). Le Français (4,5%) arrive en cinquième derrière l'Espagnol (~6%) etl'Hindi (~5%).
Et non, on ne parle pas en SMS parce que ce pseudo-langage ne permet pas de s'exprimer réellement.
Si tu as d'autres questions, surtout n'hésite pas, je suis là pour t'éclairer et pour t'aider.
Yth, moi grand guru, moi illuminé.
[^] # Re: Conjonction de coordination
Posté par Anonyme . Évalué à 3.
1 - Mandarin (largement devant, parlé par 3 fois plus de monde que l'Espagnol)
2 - Espagnol
3 - Anglais
4 - Arabe
5 - Hindi
6 - Portugais
7 - Bengali
8 - Russe
9 - Japonais
10 - Allemand
11 - Français
(Source : Science & Vie octobre 2006)
[^] # Re: Conjonction de coordination
Posté par Uvoguine . Évalué à 3.
[^] # Re: Conjonction de coordination
Posté par Yth (Mastodon) . Évalué à 5.
http://www.populationdata.net/palmareslangues.php
J'ai calculé mes pourcentages avec une base de 6,5 milliards de gens sur terre selon : http://www.populationmondiale.com/
Donc plus récent, il faudrait revoir les pourcentages un poil à la hausse, mais ça ne change pas fondamentalement les ordres de grandeur et pas du tout les écarts.
Sur wikipedia on a des chiffres encore différents.
http://fr.wikipedia.org/wiki/Liste_des_langues_par_nombre_to(...)
L'anglais arrive en quatrième, derrière le Mandarin, l'Hindi et l'Espagnol.
Et le Français tombe à la neuvième.
Le nombre de personne parlant le français, l'anglais et le mandarin est le même entre mon premier lien et wikipedia, donc les pourcentages et écarts restent les mêmes, c'est juste qu'il y a d'autres langues qui s'intercalent. Ca a l'air d'une fiabilité impressionannte tout ces chiffres...
Bref, on est loin d'un 90% de gens parlant anglais...
Yth.
[^] # Re: Conjonction de coordination
Posté par Sylvain Sauvage . Évalué à 5.
Personne ne fait de recensement avec la question : « quelle(s) langue(s) parlez-vous ? ». On en est réduit à faire soit des sondages et des généralisations, soit des raisonnements approximatifs (genre « Y est la langue officielle de X, qui est allé à l'école en X parle Y », ou, pire, « qui habite X parle Y », raisonnements douteux en général, extrêmement douteux quand les chiffres pour « habite » ou « est allé à l'école » sont eux aussi très douteux).
Et puis les données sont parfois floues pour des raisons politiques, etc.
En tout cas, les ordres de grandeur (c'est-à-dire les chiffres, en étant très large, à ±100 %…) sont justes.
Même si un milliard de gens parlaient l'anglais (et savaient le lire…), on est toujours loin de 90 %.
Ah ! non, ça y est. Je viens de comprendre : les pauvres, ça compte pas. C'est vrai, c'est tellement évident qu'on l'oublie parfois. (Évidemment encore, ceux qui ne parlent pas anglais sont forcément pauvres…)
[^] # Re: Conjonction de coordination
Posté par Yth (Mastodon) . Évalué à 2.
Le plus hallucinant étant le compteur qui donne la population humaine à la personne près, à la seconde près !
C'est forcément une extrapolation de la courbe de l'évolution de l'évaluation de la population mondiale, mais c'est pas marqué explicitement.
Bref, un site francophone sur les logiciels libres c'est bien, c'est utile au niveau mondial, ce n'est pas une goutte d'eau. Et les traductions des logiciels c'est bien (c) (r) tm, même quand c'est une langue très peu parlée comme le Catalan, au pif.
Yth.
[^] # Re: Conjonction de coordination
Posté par spotty . Évalué à 4.
http://linuxfr.org/submit/comments,21159,739991,1.html#reply
[^] # Re: Conjonction de coordination
Posté par gpe . Évalué à 3.
[^] # Re: Conjonction de coordination
Posté par Toufou (site web personnel) . Évalué à 3.
Beh c'est l'avantage de notre fabuleux système de notation linuxfr : si une majorité de gens considèrent que le message "pollue le fil", alors il est joyeusement noté inutile et disparait, collapsisé (néologisme uniquement destiné à nourrir le troll) dans un petit [+] :)
Si ce n'est pas le cas, alors on peut imaginer qu'une majorité de votants considère que ce bulletin correctif est pertinent et donc, a tout à fait sa place dans les commentaires. Celà voudrait dire qu'une majorité de votants pense que l'otograf é lasse 1 tax c oci 1portant que le sujet traité, car un sujet illisible est inexploitable.
Et puis, ça reprend l'idée du patch et permet parfois à l'auteur de s'améliorer s'il tient compte des remarques : il n'y a qu'à voir les grands progrès de beretta_vexée.
[^] # Re: Conjonction de coordination
Posté par gpe . Évalué à -3.
Alors je crois que je vais vous laisser entre spécialistes de notre chère langue sur linuxfr.org alias languefr.org et aller lire les nouvelles ailleurs.
Merci de me "moinser" car ce message n'a rien à voir avec le sujet du fil.
Bye!
[^] # Re: Conjonction de coordination
Posté par Yth (Mastodon) . Évalué à 2.
La première chose à faire si ce genre de considération t'agacent, c'est la première qui devrait te venir à l'esprit et aussi la plus simple à mettre en oeuvre : tu ignores et tu passes à la suite.
Est-ce si difficile à faire malgré tout ? Je suis sûr que tu en es capable, courage !
Yth.
[^] # Re: Conjonction de coordination
Posté par gpe . Évalué à -3.
Je l'avais d'ailleur mentionné dans ma réponse...
J'aimerai bien ignorer ces messages mais c'est malheureusement difficile car sur la page d'accueil le petit symbole qui indique qu'il y a de nouveaux messages sur un fil ne fait pas la distinction entre les messages traitant du sujet et ceux sur la langue française! Alors j'ouvre l'article je le parcours et "blablabla" et "blablabla"... J'en arrive même à louper des messages intéressants!
Bon comme de toute façon on sera jamais d'accord pas la peine de continuer pendant 100 ans.
Fin de transmission.
[^] # Re: Conjonction de coordination
Posté par Anonyme . Évalué à 0.
[^] # Re: Conjonction de coordination
Posté par kowalsky . Évalué à 3.
Moi ça me fatigue aussi mais en même temps, si il n'y avait pas les 15 messages
à propos de grammaires ou autres, il n'y aurait pas plus, pas moins, de messages
traitant du sujet principal.
[^] # Re: Conjonction de coordination
Posté par iug . Évalué à -1.
Les deux catégories qui me plairaient sont "Langue Française" et puis "Je suis contre le fait que cette news soit passée". Ou bien une catégorie "forme", une catégorie "forme".
Sa me permettrait d'avoir des commentaires entre 20 % et 300 % plus denses en réflexions atour du fond de la news.
[^] # Re: Conjonction de coordination
Posté par kowalsky . Évalué à 0.
C'est simple, clair, rapide...
Ta solution complexifierais la chose je pense.
[^] # Re: Conjonction de coordination
Posté par beagf (site web personnel) . Évalué à 1.
En théorie c'est le rôle que devrait remplir le lien "inutile", mais entre la théorie et la pratique...
# Sécurité ?
Posté par chimrod (site web personnel) . Évalué à 3.
[^] # Re: Sécurité ?
Posté par Markov . Évalué à 10.
Cela etant, les developpeurs X travaillent dans "l'ombre" a regler tous ca en decouplant petit a petit le serveur X des drivers afin d'arriver a avoir l'ensemble des drivers carte graphique de X a utiliser l'architecture DRM/DRI ou une architecture type framebuffer. Ainsi X n'aura plus besoin d'avoir les privileges qu'il a aujourd'hui. Il faudra encore certainement attendre quelques annees pour voir cela arriver...
[^] # Re: Sécurité ?
Posté par clearstream . Évalué à 9.
Les développeurs d'Xorg l'ont dit, Alan Cox l'a dit, ce n'est pas un trou de sécurité. Donc il n'est pas prêt d'être corrigé. En tout cas, il est tout en bas de la pile des priorités.
> http://linuxfr.org/2006/05/15/20813.html
Cette news n'aurait pas dû passer en l'état.
Je n'en dirais pas plus, sinon mon karma va encore en prendre un coup.
[^] # Re: Sécurité ?
Posté par neologix . Évalué à 5.
Il y a quand même un (gros) problème avec le serveur X. Après, on est libre de l'appeller bug, problème de sécurité, ou "undocumented feature"...
[^] # Re: Sécurité ?
Posté par Markov . Évalué à 1.
# GTK, QT et les autres
Posté par gentildemon . Évalué à 9.
Concernant le portage de gros toolkit tel que que GTK+, est-il déjà commencé/envisagé par l'équipe principale ?
Quant est-il pour QT ?
[^] # Re: GTK, QT et les autres
Posté par JoeBar . Évalué à 5.
Pour répondre à ta question, je ne sais pas ce qu'il en est, je ne peux donc pas répondre à ta question "qu'en est-il ?"
[^] # Re: GTK, QT et les autres
Posté par esdeem . Évalué à 7.
Et hors de moi, je sors.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Langue Française SusKe
Posté par iug . Évalué à -3.
Si je lis Linux-fr c'est uniquement parce que, n'ayant pas 2000 commentaires par article on a moyen d'être entendu en commentant.
C'est pas parce qu'il est en Français. Ce qui est appréciable dans le fait qu'il est français, c'est qu'il touche des gens proches géographiquement pour la plupart, d'où un certains nombres de bouffes qui ont eu lieu, ainsi que les annonces des LUGs, etc...
En dehors de ça il pourrait être en Anglais, ça serait pareil pour moi.
A quand un en.linuxfr.org ? Et puis dans un bel Anglais massacré façon Français moyen. Personnellement je préfèrerais. On n'aurait pas tout ces boûts de threads débiles sur la correction du langage.
[^] # Re: Langue Française SusKe
Posté par marseillais (site web personnel) . Évalué à -3.
Au moins lui y ajoute une touche d'humour pas désagréable. Et peut être même peut on y voir une touche sarcastisque face a ces commentaires sur la grammaire. Bref il faut être tolérant dans un sens comme dans l'autre. Un commentaire corrigeant une faute d'orthographe avec un tant soit peu d'humour a a mon avis tout a fait sa place ici.
[^] # Re: Langue Française SusKe
Posté par tao popus . Évalué à 2.
Oui, avec l'aide de cairo c'est déjà partiellement fait.
[^] # Re: Langue Française SusKe
Posté par Yth (Mastodon) . Évalué à 9.
Avec *tout* ce que ça implique, en particulier qu'il est fréquenté par tout un tas de français, et qu'on y écrit en français.
L'avantage énorme d'un site où on écrit en français c'est que tout les francophones qui n'ont pas ta maîtrise merveilleuse de la langue de shakespeare massacrée peuvent aussi le lire et y participer.
De plus, le fait d'écrire en français, pour un public majoritairement francophone, permet assez souvent d'avoir des textes bien écrit ou humoristiques, et surtout avec une précision qu'un anglais approximatif ne permet pas d'obtenir, ce qui rend globalement le contenu général du site à la fois plus intéressant et plus abordable. Evidemment surtout pour le public francophone.
Le corollaire étant que le français moyen avec sa réputation de râleur, quand il fait des efforts pour écrire correctement râle quand son voisin fait pas les mêmes efforts, ya pas de raison.
De plus, ces commentaires tout à fait pertinent sur le langage que nous pratiquons tout les jours pour nous comprendre les uns les autres, et qui est régulièrement massacré lui aussi, pas la peine d'aller chercher outre-manche, permettent aux gens d'en apprendre un peu sur leur belle langue, tout en s'instruisant des choses du monde du libre.
Je tiens par ailleurs à ajouter cette remarque qui dit que quand on écrit "quant est-il" au lieu de "qu'en est-il", il y a fort à supposer que l'auteur utilise une expression orale dont il comprend très certainement le sens, mais qu'il ne sait pas décortiquer pour en comprendre le sens via les mots utilisés. Il est fort probable que de manière générale ce genre d'erreurs puissent marquer une compréhension relativement approximative de ce qui a été écrit par son auteur lui-même.
Est-il utile de t'expliquer en long, en large, en travers et en zig-zag l'intérêt qu'il y a à ce que l'auteur d'un texte comprenne ce qu'il écrit lui-même, pour en comprendre nous-même, simples lecteurs, le sens ?
Savoir s'exprimer c'est aussi un moyen d'être libre.
Tout est une question de communication, mon message peut se résumer ainsi :
LinuxFR est en français ce qui est un avantage fort appréciable pour avoir une bonne communication autour du libre dans le monde francophone. Meilleur est le français parlé sur ce site, meilleure est la communication, donc le contenu est de plus grande qualité.
CQFD.
Yth, qui a vraiment appris à écrire français en même temps qu'il a appris à utiliser Linux, et pour la même raison : l'amour de la liberté.
[^] # Re: Langue Française SusKe
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Langue Française SusKe
Posté par Gniarf . Évalué à 2.
T'entends !!!!
DES CHIPS!
C'est tout c'que ca t'fait quand je te dis qu'on va manger des chips?
[^] # Re: Langue Française SusKe
Posté par inico (site web personnel) . Évalué à 3.
Raison evoqué par le sous-système: «Citation inconnue»
[^] # Re: Langue Française SusKe
Posté par plic . Évalué à 4.
Tu me fais penser à Georges, politiquement.
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Langue Française SusKe
Posté par dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: Langue Française SusKe
Posté par Yves Bourguignon . Évalué à -1.
tous - les - jours...
[^] # Re: GTK, QT et les autres
Posté par Ant . Évalué à 4.
Alors si c'est pour servir d'alibi intellectuel à des gens qui ont de toute façon envie de bavasser, autant ouvrir une section "linux bavardage", ça permettra aux autres de pas s'agacer avec des commentaires oiseux !!
[^] # Re: GTK, QT et les autres
Posté par esdeem . Évalué à 3.
Aurais-je dû mettre un smiley une émoticone?
Tant qu'a faire autant illustrer la grammaire par un exemple parlant et humoristique, plutôt que de se fendre d'un magnifique prose agressive pour attirer la foudre et la honte sur un gars qui s'est mal relu.
Personnellement, je suis dyslexique et c'est parfois un calvaire d'écrire.
Alors la condescendence d'autrui face aux gens qui font des fôtes d'ortograffes finit par me lasser.
< / fautes d'orthographe inside ... euh ... à l'intérieur >
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: GTK, QT et les autres
Posté par Uvoguine . Évalué à 2.
[^] # Re: GTK, QT et les autres
Posté par gentildemon . Évalué à 5.
J'avais bien l'impression que quelque chose clochait quand j'ai posté, mais je ne voyais pas...
En fait, j'ai fait un mélange entre 2 tournures :
- Quant à QT, [y'a t'il quelque chose de prévu] ?
- Qu'en est-il pour QT ?
Si je ne m'étais pas emmelé les pinceaux, ça aurait donné :
- Quant à QT, qu'en est-il ?
[^] # Re: GTK, QT et les autres
Posté par skimmy . Évalué à 4.
Pour QT, je sais pas.
[1]http://lists.freedesktop.org/archives/xcb/2006-September/001(...)
[^] # Re: GTK, QT et les autres
Posté par gS . Évalué à 7.
Cairo is a graphics library that supports vector graphics and image compositing that can be used with GDK. Since 2.8, GTK+ does most of its drawing using Cairo.
En gros Gtk utilise cairo pour la majorité de son rendu.
Cairo permet de dessiner entre autre en utilisant XCB ( et Xlib, opengl...). Donc si j'ai bien tout compris, Gtk+ pourrais déja bénéficier d'XCB...
Les distributions ne disposent peut être pas encore du cairo avec XCB, mais si ca peut marcher et que c'est vraiment plus efficace, ca ne devrait pas tarder à se généraliser.
[^] # Re: GTK, QT et les autres
Posté par tao popus . Évalué à 2.
Donc, Xrender =>rendu en 3d en utilisant l'acceleration OpenGL si disop, donc deja beaucoup plus rapide.
XCB => acces plus rapide au fonction de rendu accelérées en 3d, donc rend rapide ce qui restait lent :D.
Ca devrait faire des jolies petites choses tout ca.
[^] # Re: GTK, QT et les autres
Posté par Jerome Herman . Évalué à 5.
Apparament là on est plus très loin.
Si dans les jours qui suivent on a pas eu de gros changement de nommage/definitions/headers ca va devenir faisable.
# Gros titres à sensations
Posté par salvaire . Évalué à 6.
Moi j'ai compris qu'il y a des cas où la xlib n'est pas optimale. Que l'architecture client-serveur à un coût. Et que X est inutilisable sur un réseau sous-dimensionné. Un rapide survol de http://www.linuxshowcase.org/2001/full_papers/massey/massey.(...) ne me permet pas de conclure que XCB va accélérer dix fois GTK+ en non déporté. L'intérêt de XCB semble plus subtile que les gros titres à sensations.
[^] # Re: Gros titres à sensations
Posté par Vivi (site web personnel) . Évalué à 3.
... et même en déporté. La Xlib n'est pas complètement synchrone non plus (pour s'en convaincre, voir l'aide de n'importe quelle appli GTK+, en particulier l'option --sync Make X calls synchronous).
GTK+ fait déjà pas mal attention à limiter les "round-trips" entre le client et le serveur.
[^] # Re: Gros titres à sensations
Posté par beagf (site web personnel) . Évalué à 10.
Ensuite, la citation du site est en effet plus nuancée, mais si tu regarde la liste qui est donnée juste après dans la page que tu donne, tu peux voir apparaître "latency hidding" et "threaded application". Or, nombreuse sont les application graphiques qui utilisent les threads, mais surtout les problèmes de latence sont commun à tous les programme qui utilisent la Xlib.
Bien sûr pour beaucoup cette latence est à peine perceptible, mais elle est toujours là. La faire disparaître contribuerait à rendre nos bureau plus réactifs.
Il faut aussi noter que même dans le pire des cas, en théorie XCB ne ralentit pas une application. (en theorie, puisque en pratique cela depend de la manière dont son codés chaques versions) En effet la Xlib envoie des requètes via le protocole X, éxactement ce que permet de faire XCB, mais d'une manière différente.
Mais dans la majoritée des cas la Xlib attend la réponse à la requète avant d'envoyer la suivante, là ou XCB te permet de traiter la reponse au moment ou tu en a rééllement besoin.
Un bon exemple est donné dans le tutoriel du wiki, il consiste à créer 500 atomes X. La version Xlib envoie une requète pour créer un atom attend la réponse et passe au suivant 500 fois de suite. La version XCB envoie 500 requète de création d'atom puis attend les réponses, donc pendant que les première requète et leurs réponses ce baladent sur le réseau, les suivantes sont envoyées.
Et même en local les performance sont meilleures, sur le PC de la personne qui à écrit le tutoriel la version XCB est environ 25 fois plus rapide. J'obtient à peu près le même ordre de grandeur sur le miens.
Bien sur cet exemple est un cas extrème et le boost de performance ne sera jamais aussi élevé, mais il y a quand même à gagner si les applications (et donc principalement les toolkit) sont migrés vers XCB.
Ce n'est pas pour rien que dans la plus parts des toolkit, il y a une utilisation des fameux roundtrips, la latence est un vrai problème que résoud XCB.
Bien sur tout n'est pas rose, notament XCB est plus bas niveau que la Xlib, et certaines choses simple à faire avec cette dernière deviennent tout de suite plus complexe. C'est pourquoi il y a aussi à écrire des bibliothèques de fonctions spécialisée et optimisée pour la XCB tout comme cela fut fait pour la Xlib.
PS: Je ne sais pas si tu as bien compris la phrase "ce qui accélérerait un maximum d'applications rapidement.". Le maximum fait référence au nombre d'application et le rapidement au temps nécéssaire pour obtenir ce gain de performance, il n'y a aucun ordre de grandeur donné. Le gain ne sera surement pas x10.
[^] # Re: Gros titres à sensations
Posté par Anonyme . Évalué à 6.
Neanmoins, XCB n'a pas ete tres profile, donc il y a de (tout) petits gains possibles.
Sinon, le gain que donne XCB lors du test de creation des atomes est a relativiser : certes XCB etait 25 fois plus rapide sur ma machine, mais le temps lui meme etait tres petit.
Neanmoins, ecore (ecore_evas) peut beneficier de cette amelioration. A chaque creation d'un ecore_evas (chaque fenetre creee par ecore), il y a creation de 200 atomes. Donc, je dirais un bon boost pour le demarrage d'une appli faite avec ecore_evas.
Il ne faut pas s'attendre a des miracles avec XCB. L'avantage d'XCB, outre son cote asynchrone, est son cote thread-safe, sa legerete en memoire par rapport a Xlib. Les applis pourraient etre plus "reactive" qu'avec la Xlib, mais il faut bien programmer l'appli.
[^] # Re: Gros titres à sensations
Posté par briaeros007 . Évalué à 1.
Ca me rapelle un programme ou j'avais pas du tout optimisé une recherche dans un tableau parce que je pensais qu'on ne l'utiliserais presque jamais (on me l'avais dis pourtant : ne pas penser !).
bon ben le profiling m'as permis de voir qu'on l'utilisait en réalité pas mal sur de grosses données.
Bon ben on est passé d'une dizaine de minute à une trentaine de seconde après profiling \o/
comme quoi pas forcément petits les gains ;)
est son cote thread-safe,
vu que les machines multiproc/multicore commence à se répandre, je pense que de plus en plus de personnes vont essayer d'utiliser des thread (ou tout du moins j'espère :-d ) , Le thread-safe me parait donc comme quelquechose permettant d'augmenter la vitesse, non pas parce que les comms seront plus rapide , mais parce faire 2 (ou n) threads permettra réellement de gagner des perfs, et pas juste utile dans un point de vue du fonctionnement du programme.
[^] # Re: Gros titres à sensations
Posté par Anonyme . Évalué à 6.
Il faut aussi definir la notion de rapidite, et plus precisement dans quel cadre XCB est plus rapide.
Si c'est pour de l'animation, ce qui va prendre le plus de ressources, ce sont les transmissions de donnees et les appels a GetImage / PutImage (via la memoire partagee ou non). Dans ce cas, XCB n'apporte pas de gain notable par rapport a la Xlib, et est meme un tout petit peu moins performant.
Si c'est pour la communication entre le client X et le serveur X, oui, il y a des gains a prendre. En pourcentage, ca peut etre gros, mais le temps lui-meme n'est pas forcement gros (25% de 0.0001 seconde, ca n'est pas enorme).
Je ne suis pas en train de casser XCB : je sui un des dev, et je crois en cette bibliotheque ;) Mais je tiens juste a relativiser les propos.
Attention, etre thread-safe ne veut pas dire que le prog va correctement gerer l'utilisation de plusieurs processeur. Ca veut juste dire que si XCB est utilisee dans un programme multi-threadé, ses donnees ne seront pas partagees avec les autres threads et donc, qu'il n'y aura pas de probleme de corruption de donnees. La Xlib n'est pas thread-safe et rend son utilisation dans un prog multi-threadé difficile.
[^] # Re: Gros titres à sensations
Posté par briaeros007 . Évalué à 3.
Ca veux aussi dire que tu peux donc faire deux thread sur une interface graphique, et les deux threads s'occupe de traitement != .deux fenetres dans une gui géré par 2 threads !=, c'est pas possible ? (je ne me suis jamais vraiment interessé au systeme de gui ,e me suis arrété à swing en java:-D).
Sinon on est bien d'accord que ce n'est pas à XCB de faire les threads, et ce n'etait pas du tout le but de mon précédent commentaire. Juste que si xcb est threadsafe, il ne sera pas un bottle neck lors de l'utilisation de threads ;)
[^] # Re: Gros titres à sensations <= il est ici
Posté par clearstream . Évalué à 2.
Il y a peut-être une erreur :
- "ce qui accélérerait un maximum d'applications rapidement"
Ce n'est pas le seul but de XCB.
Sinon XCB est un effort de plus de 2 ans !
Ça mérite un titre "fort".
# Et les performances ?
Posté par ナイコ (site web personnel) . Évalué à 6.
J'avais lu, il y a plus d'un an, une explication concernant le fonctionnement de NX, pourquoi c'est plus rapide [1], etc...
Question : Est-ce que XCB allège le traffic réseau ? Sinon, et c'est presque hors-sujet, est-ce que X va intégrer les améliorations visiblement énormes de NX à ce niveau ? XCB peut-il enlarger mon serveur de terminaux ?
[1] On y parlait d'ailleur de drogues très en vogue dans le X, les "roundtrips".
[^] # Re: Et les performances ?
Posté par clearstream . Évalué à -1.
> Est-ce que XCB allège le traffic réseau ?
Peut-être.
> XCB peut-il enlarger mon serveur de terminaux ?
T'aurais pas quelque chose à compenser ?
# Quid de la XCL ?
Posté par Ontologia (site web personnel) . Évalué à 6.
Je suppose donc qu'une fois cette librairie au point, testée, figée dans son ABI, on pourra mettre la Xlib aux oubliettes ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Quid de la XCL ?
Posté par mickabouille . Évalué à 2.
# petite question en passant ?
Posté par Rico . Évalué à 1.
y a-t-il un lien entre la XLib, et X.org ?
si oui, quel est-il ?
et aussi, est-ce que XCB, peut remplacer XLib dans cet usage ?
c'est peut etre pas clair, mais bon, je suis curieux alors je demande toujours
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.