Logiciel : X11R7.0 sous le sapin de Noël
Posté par Calim' Héros (Jabber id, page perso, ). Modéré le 22 décembre 2005.
La principale avancée de X11R7.0 est sa modularisation (passage d'une archive de sources unique à 287 archives distinctes) et son "autotoolisation", c'est-à-dire le passage à autoconf et automake pour la configuration et la compilation. Cette version est accompagnée d'une petite soeur : X11R6.9. Cette dernière est le pendant "classique" de X11R7.0, comprenant le même code mais non modularisé, et avec l'ancien système de compilation (imake). À l'avenir, la branche monolithique devrait être maintenue, mais les ajouts de nouvelles fonctionnalités seront concentrés sur la branche modulaire (avec l'objectif d'un X11R7.1 à la mi-2006).
Par ailleurs, le chargeur de modules utilise désormais un protocole basé sur libdl et permet entre autre l'utilisation de cette nouvelle mouture sur MIPS, Motorola 68000, HP PA/RISC, etc, ainsi que la compatibilité binaires des modules sur une même architecture (un module compilé sous Linux/x86 pourra donc être utilisé sous OS2/x86, FreeBSD/x86, Hurd/x86).
On notera aussi l'apparition dans ces versions de EXA, une alternative à XAA (XFree86 Acceleration Architecture) pour l'accélération 2D, qui promet de meilleures performances avec les cartes graphiques modernes. Cette architecture n'est cependant pour l'instant supportée que par les drivers i128, radeon et sis, et n'est pas activée par défaut.
On retiendra enfin nombres d'améliorations du support Multi-Head et une réécriture complète de Xinerama, le support (expérimental) de l'accélération 3D pour les cartes Radeon r3xx et r4xx, ou encore la possibilité d'utiliser les définitions de clavier xkbdesc qui supplantent le traditionnel xkbdata et offrent plus de cohérence et de souplesse.
NdM : merci à Guillomovitch pour avoir également proposé la news.
![[en]](../images/en.png)
L'annonce officielle (918 hits)-
Le site de Xorg (1319 hits)
-
Les Release Notes (617 hits)
> Lire la dépêche (144 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #664063.
Run by 
Cette page a été générée par Templeet en 0.2747s (dont 0.024 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cher Père Noël...
Pourrais-je un jour espérer, lorsque je déplace une fenêtre, de ne plus voir des trainée peu harmonieuse suivre la fenêtre ?
Pourrais-je un jour expérer que X me prenne moins que les 60 à 120 Mo d'occupation mémoire habituel ?
Pourrais-je un jour espérer la gestion de la transparence en natif ?
Bref, quand verra-t on évoluer un système qui fut certes révolutionnaire en son temps, mais un peu pâlo et usine à gaz face à sa concurrence (pourtant tout aussi usine à gaz) Windows et Mac OS (leur gestionnaire graphique s'entend) ?
Père Noël, d'avance, merci...
[^]Re: Cher Père Noël...
C'est peut-être dû à la puissance de ma machine (faut pas exagérer non plus ...), mais je ne vois pas de trainées moi .. et je déplace les fenêtre en voyant le contenu de celles-ci...
Pour ce qui est de la mémoire, je suis d'accord, mais comme je suis dans un bon jour, je vais dire si ça tombe, cette nouvelle version, avec sa modularité, peut permettre une avancée dans ce domaine ?
Pour la transparence... ben moi c'est pourri vu que j'ai une ATI et que j'utilise fglrx pour pouvoir faire mumuse en 3D
[^]Re: Cher Père Noël...
On va encore me faire du racisme anti lèse majesté ("mon dieu ! Il a blasphémé contre Xorg !!! Brulez le !!"), mais sur ma machine (une Duron 1 Ghz, 512 Mo) et depuis six ans que j'utilise Linux, j'ai toujours eu des trainées, j'ai toujours eu des affichages extrêmement lent. Et au début c'était cata...
Il faut reconnaître les énoooormes progrès.
Windows, j'en suis désolé, n'a pas ce genre de défauts, il en a sur ce point, mais moins (Note pour les anti windows primaire : je supporte très mal de devoir utiliser windows pour autant).
J'ai personnellement taté du Mac OS X et j'ai complètement halluciné, la beauté, l'intégration du système et le sentiment esthétique qui en émane est quelques chose d'UNIX.
De plus, j'ai testé Xcomposite, permettant de gérer les transparence sous X, et, malgré, mon driver NVidia officiel, c'était d'une lenteur affreuse.
Je vais me faire moinsser, mais il faut que le monde du libre accepte de regarder la réalité en face sous peine de devoir subir de grosses déconvenues...
[^]Re: Cher Père Noël...
est quelques chose d'UNIX.
Ouuuuuhh le lapsus !!
Falloir que j'en parle à mon psychiatre !
Je voulais dire "unique", bien sûr !
[+] [^]Re: Cher Père Noël...
Sur le fond tu as peut etre raison, mais ne pense tu pas que c'est aussi peut etre liée à des drivers proprietaire qu'il y'a ce gende de probleme ?
Je pense pas que la lenteur et tes trainée sont du exclusivement à Xorg, mais bel est bien aux fabricant qui developpent chacun dans leurs coins.
Pense tu que c'est normal que pour certaine carte, ca soit des devéloppeurs bénévolles qui developpent les drivers ?
Donc avant de t'en prendre à Xorg, faudrait peut etre pas se tromper de cible.
[^]Re: Cher Père Noël...
Non je ne pense pas, car lorsque j'utilise la transparence dans des jeux, soit natif sous Linux, soit utilisant Wine/Transgaming, la transparence fonctionne parfaitement.
Donc j'en conclu que je ne me trompe pas de cible.
[^]Re: Cher Père Noël...
Non je ne pense pas, car lorsque j'utilise la transparence dans des jeux, soit natif sous Linux, soit utilisant Wine/Transgaming, la transparence fonctionne parfaitement.
Ça ne veut rien dire, et n'a rien à voir.
C'est comme dire que dans une page web, la transparence marche => pourquoi ne marcherait-elle pas sur des fenêtres ?
[^]Re: Cher Père Noël...
Eh bien je supposais que la transparence utilisé par X11 se sert des fonctionnalités de la carte graphique, donc des mêmes fonctionnalités que les jeux.
NVIDIA/ATI vont pas s'amuser à développer deux circuit de gestion de la transparence (?)
[^]Re: Cher Père Noël...
Ça n'a rien à voir parce que la transparence est gérée dans la puce 3D pour les jeux 3D, et surtout que tout a lieu dans la même application !
Les serveurs X n'utilisant pas encore l'openGL, la transparence est gérée par XRender. Or render n'est pas accélérable avec XAA, l'architecture d'accélération "traditionnelle" de X. Les drivers nVidia savent l'accélérer car ils n'utilisent pas XAA.
EXA, la nouvelle architecture d'accélération, est capable d'accélérer Render. Les drivers n'ont que certaines fonctions à fournir.
Mais y'a pas sur la carte graphique une puce "transparence", une puce "faire des cubes", une puce "faire des sphères"... Ça serait bien trop coûteux !
[^]Re: Cher Père Noël...
Pour avoir utilisé un windows XP qui n'avait pas le bon driver de la carte video installé, je peux vous dire qu'il ramait plus que mon Linux et son driver nv.
[^]Re: Cher Père Noël...
Heu je vois pas comment. Quand j'utilisais Composite sans accélération, je faisais un transset sur une fenêtre et on aurait dit une image haute résolution qu'un navigateur internet (ou faille de sécurité :ça marche avec IE) en connexion internet 9600 bauds...
Mon JID est yannbng@jabber.fr
[^]Re: Cher Père Noël...
Si tu te contente juste d'activer composite, en effet, ça rame, tout simplement parce que tu n'utilises pas ta carte 3D.
Jette un ½il aux options RenderAccel et RENDER, qu'il faut activer, et là, tu vas utiliser ta carte 3D et en prendre plein la vue ;-)
[^]Re: Cher Père Noël...
Je viens d'essayer, ayant trouvé une doc expliquant quels option mettre pour mon driver proprio nvidia en particulier.
C'est afreusement lent : 2 secondes pour afficher une fenêtre.
5 mn après, plantage de de X.
Expérience pas concluente... On verra l'année prochaine.
[^]Re: Cher Père Noël...
Heu.. perso, j'ai pas de trainée qui suit la fenetre et X prend moins de 60 Mo de RAM. Pour la transparence en natif, je crois qu'il y a une option à la compilation mais je ne suis pas sur.
Concernant le gestionnaire graphique de Windows, il est extremement lourd en RAM je trouve et n'a toujours pas la transparence en natif.
Pour MacOS X, je sais pas, j'ai pas testé mais ca a l'air pas mal du tout comme OS.
[^]Re: Cher Père Noël...
>Pourrais-je un jour expérer que X me prenne moins que les 60 à 120 Mo d'occupation
> mémoire habituel ?
C'est pas la taille cumulée de *tous* les pixmaps ouvert par *toutes* les applications se connectant à X?
> Pourrais-je un jour espérer la gestion de la transparence en natif ?
Ça n'existe pas encore?
[^]Re: Cher Père Noël...
La transparence en natif, c'est avec composite, ca existe quoi.
Chez moi X bouffe dans les 30-40 Mo de ram.
\_o<~~~~
[^]Re: Cher Père Noël...
Si, c'est bien a taille cumulée, et la transparence, ça existe (xcompmgr pour l'utiliser, je crois ?)
Messieurs les insatisfaits, arrêtez tout le temps de dire que X, c'est vieux, moche et lourd : c'est faux, surtout qu'en plus, beaucoup de choses ont progressé ces dernières années sur le plan fonctionnel (meilleures fontes, XRender...).
Si j'ai une chose à demander au Papa Noel, c'est qu'il botte les fesses aux décideurs de Novelle qui a fermé (!!!) le développement de XGL (un serveur X qui bosse en OpenGL, la classe).
[^]Re: Cher Père Noël...
Mouais, enfin je disais ca moi aussi avant, et c'est vrai, mais pas complètement faux en fait :)
Depuis que j'ai récupéré cet écran ( un 22" ) j'ai accès aux joies des hautes résolution ( je suis en 1920x1440 la ). Ben je comprend pourquoi on dit que X c'est lourd, lent toussa ...
C'est pas si lent que ca, mais à chaque fois que je change de bureau virtuel je vois toutes les fenêtres se dessiner une par une ! ( bon ca vient ptet du driver nvidia je sais pas )
PS : Athlon XP 1800+, 512Mo DDR, GeForce 3 ( avec le driver officiel )
\_o<~~~~
[^]Re: Cher Père Noël...
Même résolution (parfois 1600x1200), même carte graphique et j'ai le même problème. Du coup, je n'utilise pas la fonctionnalité des bureaux multiples, mais pour être honnête à partir de 1600x1200, et à plus forte raison en 1920x1440, c'est totalement inutile :-)
[^]Re: Cher Père Noël...
Pour moi c'est quand même utile :)
Mais encore moins utile qu'avant c'est sur ...
Sur le premier bureau j'ai xchat/gaim/2 3 terminaux
Sur le second j'ai firefox ( en 1280x1024 parce que j'ai remarqué que le driver nvidia crashait moins comme ca ... )
Sur un autre j'ai en général, blender ou gimp ou vim + plein de terms, enfin un bureau "boulot" quoi :)
\_o<~~~~
[^]Re: Cher Père Noël...
J'utilise FVWM. Je peux utiliser au choix des "desks" ou des "pages". En utilisant des "desks", j'avais ce même problème. J'utilise depuis des "pages", où je ne peux pas changer le fond d'écran. Je n'ai maintenant plus ces problèmes. C'est pourquoi je ne suis pas sûr que le problème vienne de xorg.
Je pense que cela vient plutôt du Window Manager.
Selon le blog de Rasterman (développeur d'enlightenment)(http://www.rasterman.com/index.php?page=News , là où il y a des graphiques rouges-orangées, du "Sunday, 29 May 2005" ), il y aurait des différences significatives lors de l'affichage de fenêtres.
[^]Re: Cher Père Noël...
Ne te fie pas au ""benchmark"" de Rasterman.
J'ai pendant les vacances travaillé sur les performances de Looking Glass. Je souhaitais tester les performances du WM de Looking Glass par rapport à KWin par exemple. LG3D a un WM clairement plus lent que KWin.
Or le test de rasterman dit que looking glass est largement plus rapide que kwin !
En fait, le problème c'est que les WM n'ont pas d'obligation vis à vis de leur comportement. Kwin décide d'afficher *tout*, ce qui fait que lors du "benchmark" de rasterman il affiche sa centaine de fenêtres, alors que le WM de Looking Glass a pas le temps d'afficher une fenêtre qu'elle est déjà fermée !
Donc ne vous fiez pas à un benchmark que vous ne comprenez pas entièrement !
[^]Re: Cher Père Noël...
J'ai un 22" et j'ai toujours été en 1600x1200, même avec des machines moins puissantes que celle que j'ai actuellement (un bi-Athlon 2200+ 1 Go RAM GeForce Ti4200).
Et je n'ai jamais vu ce comportement de lenteur de changement de bureau virtuel en situation normale.
Par situation normale, j'entends tant que ça ne swappe pas à fond (pour relativiser le Go de RAM, il faut savoir que je fais tourner en simultané un Gnome, un KDE et un XFCE).
En général, c'est galeon (ou le plugin java avant que je passe en 1.5) qui bouffe la mémoire et fait tout swapper.
J'y suis moins sensible parce que j'ai des disques SCSI et en général, je ne vois pas que je swappe.
Mais lorsque je commence à trasher par manque de mémoire (arrive rarement) je vois clairement les fenêtres se dessiner et là je sais que qqch m'a bouffé ma RAM.
J'ai vu aussi le comportement lors de l'install de la première version de GTK "avec cairo", où ça ne devait pas être très optimisé car en regardant bien, je voyais quelques fenêtre vides durant 1 dixième de seconde.
J'ai pas vu dans KDE en revanche.
Donc il y a certainement du boulot à faire au niveau optimisation, mais ça ne me paraît pas si abysmal que ce que j'entends.
Je n'avais pas ce problème non plus à l'époque sur un Athlon 400 avec 256 Mo de RAM (où je tournais avec un seul desktop, j'ai upgradé lorsque j'en ai rajouté).
[^]Re: Cher Père Noël...
En 1600x1200, j'ai pas de problème de perf en changeant d'appli ou de bureau.
GeForce 6600 avec 256 Mo de RAM (driver proprio)
P4 2.8 GHz HT + 1 Go de RAM central
Ubuntu stable avec Gnome
Je pense que les 256 Mo de ma CG + HT (du vrai bonheur malgré les détracteurs) + 1 Go RAM rapide (mais sans plus: PC3200 de base ) doivent jouer.
La qualité des applis aussi, juste entre FF1.07 et FF1.5 c'est frappant le changement d'onglet...
[^]Re: Cher Père Noël...
Config Athlon XP 2000+, 512 MO, GeForce2 ( avec driver officiel ): pas d'ennui avec 2 sessions X et bureaux virtuels..
Ce ne serait pas un problème de swap plutôt ?
Si c'est cela, un truc péché dans Linux+ je crois:
echo 30 > /proc/sys/vm/swappiness
( valeur par défaut:60
tout va vers le swap: 100
uniquement vers swap si indispensable: 0 )
[^]Re: Cher Père Noël...
Alors je dirais que ce n'est pas X qui est en cause, mais le WM ou les applis.
J'ai un 22" en 2048*1536 et un 19" en 1600*1200 en twinview, et avec mon ancien amd 1600+ (j'ai changé depuis) le changement de bureau était presque instantané. Et j'ai 10 bureaux, dont habituellement au moins 6 remplis...
PS: config de l'époque: AMD 1600+, 515Mo, GeForce 5700, KDE. Je ne crois pas que nos cartes graphiques seules impliquent une telle différence en utilisation 2D classique.
[^]Re: Cher Père Noël...
Oui oui, c'est presque instantanné, maintenant j'y fais plus attention :)
Mais si on regarde bien, on voit tout se dessiner, mais ca vient ptet effectivement du wm puisque comme signalé au dessus y'a l'histoire des pages/desks avec fvwm. Moi je suis sous fluxbox.
Quand aux applis je pense pas que ca vienne de la, ca le fait avec n'importe quoi, gtk 1 et 2, opengl, tout
\_o<~~~~
[^]Re: Cher Père Noël...
Je suis entierement d'accord avec Ontologia.
J'adore Linux, je m'eclate avec neanmoins depuis mon passage sur MacOSX j'avoue avoir un peu de mal en revenant sous Linux....je ne parle pad de windows ou la je n'apprecie plus du tout l'interface.
Bizarremen avant mon passage sous MacOSX j'etait un pro KDE je ne comprenais pas pkoi on me parlait sans cesse de Gnome, je trouvais les outils moins bien integrés entre eux bref j'etais un anti-gnome et je n'hesitais pas a faire passer des novices sous KDE leur expliquant que l'interface etait tres proche d'un windows.
Bref je m'egare suis a mon passage chez Apple, j'ai continué d'utiliser Linux et j'ai appris a apprecier Gnome, dont l'interface semble s'inspirer du meilleur des 2 os Proprio.
J'ai teste la ubuntu breezy sur mon powerbook 15" 1ghz et Radeon 9600 et la j'avoue avoir eu du mal a supporter les trainée lors du deplacement des fenetres.
Certains n'ont pas ces trainées soit mais faite le test, lancer un firefox puis lancer la fenetre de configuration de ce meme firefox et deplacer cette fenetre, sur une grande majorite de becane il y aura des trainés.autant auparavant cela ne me posait pas de pb autant le passage sous mac et apres avoir gouté a quartz extreme et CoreImage on ne peut plus s'en passer.
Certains pensent que la 3D n'a rien a faire sur nos desktop Linux, je trouve ca dommage, il suffit de tester "expose" sous mac pour se rendre compte que c'est une fonction tres utile a tel pint qu'on se demande pkoi personne n'y avait gouter avant.et pour avoir un expose sous linux avec l'affichage en temps reel des fenetre je ne vois la que l'utilisation d'OpenGL.
Bref j'ai actuellement un toshiba Tecra M2 que je viens d'acquerir (echange avecm on T42p) car je ne peux utiliser Linux qu'en ayant les fonctions composite active et fluide, et pour le moment ma nvidia 5200 s'en charge comme il faut.
Il ne manque pas grand chose pour que linux soit parfait en tant que desktop selon moi (c'est mon avis point de troll), une bonne gestion des cartes 3D actuelles, et une utilisation d'opengl.
Certains trouvent l'utilisation d'OpenGL trop lourde pour un desktop ....chez moi et apres avoir utilisé composite l'utilisation de gnome est plus "fluide" (je me comprends) le CPU est moins solicité lors du deplacement des fenetres, et plus aucunes trainées.
Ah comme je reve d'un expose sous linux mais d'apres ce que je vois et le developpement de Xorg, cela semble arriver et pas dans si longtemps que ca.
Imaginez avec nos developpeurs de genie qui passent leur temps a pondre des applis, imaginez ce qu'ils pourraient nosu faire si notre Xorg, gnome,kde,xfce,etc pouvaient utiliser l'openGL en hard.hum le bonheur.
Mon post est pas tres comprehensible et bourré de fautes j'en suis désolé.
Juste pour préciser il ne s'agit pas d'un troll , je parle de MacOSX car j'avoue avoir trouve la une reelle innovation ou plutot une tres bonne implementation de differentes techno existantes, je prefere quand meme rester sous linux et ne pas avoir a faire comme sous windows trouver un crack pour le moindre shareware qui apporte une nouvelle fonction a Tiger.
[^]Re: Cher Père Noël...
ne pas avoir a faire comme sous windows trouver un crack pour le moindre shareware qui apporte une nouvelle fonction a Tiger.
bah ya quand meme pas mal de libre sous macos..
Pas toujours evident a trouver au milieu des freeware/shareware, mais ya de quoi faire quand meme.
Sinon, totalement d'accord avec toi, graphiquement macos a une bonne longueur d'avance sur tout le monde, et ca c'est sans compter le savoir faire en ihm des gens d'apple.
Perso, ca m'arrive encore de faire mumuse a juste bouger les fenetres tellement je trouve ca joli.
Les gouts et les couleurs apres, hein.
[^]Re: Cher Père Noël...
Ah comme je reve d'un expose sous linux [...]
Euhhh, et "Kompose" ? Sur Mandriva, en utilisant les sources "contrib" :
# urpmi Kompose
Et c'est vrai que c'est pratique.
Pan ! Pan !
Ne pas utiliser : traplinuxfrnico@univ-nantes.Fr
[^]Re: Cher Père Noël...
J'aime bcp Kompose, mais il a malheureusement la facheuse tendance à ramer pour faire ses screenshot. Chez moi, il bloque pendant 10 s très régulièrement. J'attend une mise à jour.
Mais sinon c'est assez génial comme jouet, bien que ça n'arrive pas àa cheville de celui d'Apple.
[^]Re: Cher Père Noël...
pas grand chose à voir ... et beaucoup moins pratique, joli. Je trouve
Et plus lent ...
Il y a je crois metisse (que je n'ai pas réussi a compiler) qui permet de faire un très joli exposé entre plusieurs bureaux virtuels ... d'une manière encore plus pratique et jolie.
Mais c'était dans la vidéo de démo,
La Roue du Temps
[^]Re: Cher Père Noël...
j'oubliais: http://insitu.lri.fr/metisse/
La Roue du Temps
[^]Re: Cher Père Noël...
Excellent commentaire. Je suis entièrement de ton avis.
Moi depuis que j'ai découvert MacOS X, je regarde les interfaces Linux et X11 d'un autre oeil.
Mais bon, comme tu as pu le constater, les critiques vis-à-vis de X11 ça passe pas, et tu t'es fait moinsser (moi aussi je vais l'être).
A l'époque j'avais essayé de parler de ça sur IRC, dans les journaux. A chaque fois on me répondait : ça va venir, regarde y a aussi des prototypes de serveur graphique en 3D, y a xgl, y a looking glass, y a trucmuche, y a machin.
Magnifique ! Mais aucun ne semble vraiment être lancé pour remplacer ou être intégré à X. ça fait déjà 2 ans qu'on me sort les mêmes excuses. Suffit de regarder aujourd'hui : y a rien en un peu stable, même l'extension Composite reste inutilisable.
Donc maintenant je ne dis plus rien. J'attends secrètement le jour où Microsoft va sortir Windows Vista et son bureau 3D avec transparence (et c'est dans moins d'un an). J'espère que Windows Vista sera bien, qu'il aura une belle interface, qui pète tout. J'espère uniquement cela pour qu'enfin y ait du changement sur Linux, pour qu'enfin ils commencent à se remuer le cul au niveau du serveur graphique.
[^]Re: Cher Père Noël...
Je vais me faire moinsser avec toi ! :-)
J'avoue que j'en suis arrivé comme toi à un point ou j'attend la venue de Vista pour que le monde de Linux comprenne son retard et cesse de se voiler la face en évoquant la théorie du complot. J'en ai été adepte, et j'ai du reconnaître que, s'il y a chez certain un formatage de cerveau pro microsoft, leur position dominante n'est pas du au hasard, mais a leur capacité à coller aux besoin du marché.
Après, leur logiciels ne sont jamais à la hauteur de ce qu'ils promettent, et c'est pour ça que je préfère Linux (en plus du fait que ce soit libre).
Je suis dans le même cas que toi : je dis à mes copains anti-Linux "Vous verrez, dans 6 mois, on atteindra XP !!". Même si ma Mandrake est maintenant aussi (voire plus) convivial que XP avec 3 ans de retard, on va avoir très très mal avec la sortie de Vista...
Mais s'il faut en arriver là pour qu'il y ait un réveil...
(Ceux qui me connaissent comprendront pourquoi je me bat pour un Lisaac libre : il nous faut un langage de haut niveau pour développer rapidement des logiciels bas niveau, comme un X alternatif et des choses de ce genre... Lisaac est un langage plus puissant que Java mais aussi rapide que du C)
[^]Re: Cher Père Noël...
On a déja des langages de haut niveau, on a un serpent et une pierre précieuse tu peux garder ton frêre.
[^]Re: Cher Père Noël...
Il a dit aussi rapide que C :-)
J'ignore si Lissac est aussi rapide que le C, mais ce qui est clair c'est que le serpent ou la pierre précieuse ne le sont pas..
Ocaml ne se débrouille pas trop mal au niveau perf, mais bon personellement je n'aime ni la syntaxe d'Ocaml ni celle de Lissac tandis que la pierre rouge ou le serpent sont très agréable au contraire.
Un language qui, je trouves, vaut le coup d'oeil est Scala (compilé pour JVM ou .Net pas natif malheureusement).
[^]Re: Cher Père Noël...
Il y a bien http://rubyforge.org/projects/ruby2c/
Mais j'avoue que j'y ai rien compris :/
L'apocalypse / fin du monde est proche
[^]Re: Cher Père Noël...
Pour ceux qui attendent VIsta je ne pense pas que l'interface de Windows sera revolutionnaire a ce point.
J'ai teste l'une des dernieres Build et tres franchement mes collegues et moi apres avoir patienté 1h30 pour l'install on a bien rigolé, OK il y a un effet de fondu qui lorsque les fenetres apparaissent et du plus bel effet, oui la carte gere l'affichage comme sous Mac, mais lorsque l'on lance l'equivalent d'expose sous Vista, on se rend compte d'une chose, il n'y a pas eu de reflexion complete sur l'IHM de Vista, il s'agit grosso modo d'une surcouche a l'interface actuelle, je m'attendais a une vrai refonte de l'interface.
On a l'impression d'une grosse demo technologique, qui fonctionne et et coherente mais pour une boite ou le budget de la Recherche et dev et si elevé je m'attendais a mieux.
Pour tout dire dans mon entourage (collegues informaticiens) qui sont ous pro-Windows, j'ai apres avoir installé OSX86 sur une config assez basique type PIV 2,4Ghz et intel 900 extrem eu l'agreable surprise de voir des personnes revoir completement leur avis sur macosx bizarrement sur powerpc cela ne les interessait pas et apres avoir tester sur leur propre becane ils sont tous revenu avec les memes commentaires, l'interface est hyper agreable et c'est presque un plaisir de surfer, de lire ses mails, ou meme d'ouvrir des fenetres.
Ce qui veut bien dire que mettre de la 3D partout comme va le faire microsoft n'est pas suffisant, une fois les superbes effets passés, on est quand meme toujours devant des fenetres Windows.
Apres il est evident que c'est mon avis mais j'ai quand meme l'impression si j'ai bien tout compris au futur kde 4 que meme l'IHM de kde risque d'être un peu modifié. Alors je me pose quand meme la question suivante, pourquoi microsoft n'est pas capable de modifier l'IHM de windows ?
[^]Re: Cher Père Noël...
Mais non c'est très bien l'effet fondu ! Comme ça, ça fait plus lent. Là au boulot on m'a imposé un XP, je n'y avais pratiquement pas touché sauf pour dépanner la famille, sur un PIII avec 256 Mo de RAM et ben au feeling, ça rame pas moins que moins Xorg grace à ce superbe effet de mes couilles (je sais ça peut s'enlever mais je sais plus comment, enfin je crois, bref j'espère :) ).
Niveau perf Xorg est clairement en retard, niveau feeling ça se défend. Je ne doute pas que sur un Athlon X2 5 GHz, 2 GO de RAM DDR3, GeForce 10000++ 768 Mo GDDR 5, ça se resend plus, mais c'est pas encore la config que vend carrefour aux mère de famille (c'est prévu pour la sortie de Vista) et c'est pas non plus ce qu'on trouve en entreprise.
Ça n'enlève rien au problème de fond, les limites de Xorg aujourd'hui se font de plus en plus sentir, mais soyons pas non plus alarmiste.
[^]Re: Cher Père Noël...
comme dis dans les autres commentaires
de xorg ou de xlib/wm/toolkit ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Cher Père Noël...
Personnellement c' est tout le contraire, j' en ai rien à fo***e de ce genre de fonction .
Je préfére 10 x avoir un support correct des tablettes graphiques, avoir un gain en perf 2d/3d, ou un support multi-écrans amélioré, etc, c' est du concret ça aide à mieux travailler (ben oui un ordinateur à la base c' est un outil) .
Alors oui , composite n' est pas utilisable (d 'aprés ce que tu dis), mais franchement c 'est pas une priorité.
L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.
[^]Re: Cher Père Noël...
c' est du concret ça aide à mieux travailler
Oui mais essaye MacOSX et rend toi compte de l'ambiance que réussi à dégager l'os. On se sent chez soi, c'est beau, c'est fluide, ca répond bien.... Ca stimule l'intellect.
[^]Re: Cher Père Noël...
C'est bizarre, moi, je trouve bien au contraire que l'interface graphique de Mac OS X rame comme c'est pas permis.
Même sur un Bi-G5 à 2,4 GHz, le redimensionnement d'une fenêtre est catastrophique tellement c'est lent. ça saccade, ça fait des trainée, c'est ignoble.
Franchement, je prefère mon linux.
Et si je compare les performance entre Mac OS X et Linux sur mon iMac G3... Linux sort là encore grand vainqueur par KO.
[^]Re: Cher Père Noël...
heuu, tes potes t'ont fait une blagues et on remplace ce qu'il yavait dans ta machine ou quoi?
j'ai un ibook G4, 12', meme en mode economie d'energie, j'ai jamais reussi a le mettre en defaut... Et pourtant, je fait du montage dessus, ca pompe grave en perf et je fais souvent mumuse avec expose et la transparence (genre mater une video derriere un terminal transparent, ca m'eclate :-P)
[^]Re: Cher Père Noël...
Sauf ton respect, franchement je ne pense pas ce genre de fonction soit essentiel. C' est marrant 1/4 d'heure mais pas plus (pour moi).
Comme tu le dis tu fais "mumuse", et pour ce qui est de X.org je pense qu' il y a d' autres choses à voir avant (voir certains post trés intéressant en dessous).
L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.
[^]Re: Cher Père Noël...
pour la transparence, d'accord, c'est un gimmick, ca sert a rien honnetement, ca fait juste plaisir a l'oeil (donc pas totalement inutile non plus, mais loin d'etre prioritaire).
Et encore, pour ceux qui utilisent un dock, c'est quand agreable de faire passer une fenetre derriere sans la masquer.
Disons que ca apporte une certaine coherence dans le bureau.
Pour les ombres des fenetres par contre, c'est un confort visuel sans commune mesure, en plus de permettre de retrouver immediatement la fenetre qui a le focus et qui en plus permet de se debarasser des bordures des fenetres par la meme occasion.
Quand j'etais encore sous KDE, j'utilisais le theme Baghira qui singe donc Aqua, et qui supprime donc les bordures des fenetres.
Je ne compte plus le nombre de fenetres que j'ai fermee accidentellement par confusion.
Je ne compte plus le nombre de fois ou je n'ai pas vu une popup apparaitre.
Ca apporte *VRAIMENT* un plus.
Quand a expose, ou plutot kompose, je trouve ce genre de choses inutilisable sans rendu 3D, seule l'animation en temps reel des fenetres permet de comprendre ce qu'il se passe.
Bref, fonctionnellement, c'est sur que ca n'apporte pas enormement, par contre en confort d'utilisation, ya pas photos : c'est loin devant.
Mais ca ne fait pas tout non plus, le confort d'utilisation vient aussi de la conception de l'IHM et du bureau en general, l'apport de la 3D ne va pas magiquement rendre un bureau agreable a utiliser.
Apres, quand a savoir s'il vaut mieux avoir une tablette graphique ou les ombres.. bah je sais pas trop, c'est peut etre des fonctionnalites qui peuvent etre developpees en parallele par des equipes differentes ?
[^]Re: Cher Père Noël...
dire que la fonction expose ne sert a rien je pense qu'on ne peut affirmer ça que si l'on a jamais essaye de l'utiliser sous MAcosx.
en gros plus besoin de fermer ou reduite les fenetres, plus besoin de faire passer la souris sur la barre des taches et d'attendre l'affichage de l'info bulle pour avoir une idee d'ou pointe cette fenetre, et je ne parle meme pas du nombre de fois ou je clic sur une console qui est dans la barre des taches mais arf zut c'est pas la bonne je vais cliquer sur celle d'a cote.
Bref la j'appuye sur F9 ou je vais avec ma souris dans l'angle et voila toute mes fenetre qui sont a l'ecran il me suffit de choisir celle que je veux
[^]Re: Cher Père Noël...
Cette manie de lire un post en diagonale et de repondre completement a cote...
Je dit pas que expose ne sert a rien, je dit que kompose est inutilisable en pratique sans le rendu 3d qui apporte toute la fluidite indispensable a ce genre de fonctionnalite.
Et je dit ca justement parce que j'utilise expose et dashboard au taquet sous macosX . ;-)
[^]Re: Cher Père Noël...
oupss desolé effectivement j'ai mal compris, je suis de ton avis j'ai essaye kompose et effectivement j'ai trouve ca gadget en revanche qq'un a t'il deja teste topdesk sous windows, c'est hallucinant comme cette appli est rapide je ne sais vraiement pas comment le gars a reussi une telle chose
[^]Re: Cher Père Noël...
F9 ... on peut aussi mettre sa souris dans un coin de l'écran ...
et aussi, il existe un autre exposé qui te permet d'afficher le bureau sans minimiser toutes les fenêtres, très pratique aussi si tu veux garder une séparation entre tes fenêtres minimisées et celles que tu veux cacher temporairement juste pour voir ton bureau.
et exposé, ce n'est pas qu'un screenshoot ou approchant, tu peux même voir par exemple une barre d'avencement défiler en temps réel.
Ca doit être pratique pour voir si on a fini l'install d'un logiciel ou le téléchargement. (oui, je n'utilise pas OSX personellement, je le regrette un peu)
La Roue du Temps
[^]Re: Cher Père Noël...
>Je ne compte plus le nombre de fois ou je n'ai pas vu une popup apparaitre.
Heu si t'as besoin d' effets d'ombrages pour ça, c'est ton opticien que tu devrais aller voir là, et vite :)
[^]Re: Cher Père Noël...
Je me suis mal exprime en fait, desole.
Cas typique : une appli qui ouvre une fenetre modale, qui elle meme ouvre une autre fenetre modale.
Tu bidouilles dans la 3 ieme fenetre, au final tu la ferme, tu te retrouves donc avec la fenetre mere et la premiere modale l'une sur l'autre.
En pratique : amarok, preferences et une sous fenetre des preferences.
Ou tout autre configuration de ce style, c'est pas bien dur a creer.
Si t'as oublie que t'etais dans une sous sous fenetre, tu te retrouves a cliquer dans ta fenetre mere en te disant : mais bordel, pourquoi j'ai pas le focus la dessus?
=> avec un ombrage tu te poses meme pas la question tu le vois d'office.
Et le cas de figure se presente tres souvent avec des fenetres en mosaique. Ca m'arrive plusieurs fois par jours au taff avec mes 2 explorateurs de fichier en mosaique verticale sous windows. =>comme quoi, meme avec des bordures de fenetres...
[^]Re: Cher Père Noël...
effectivement le redimensionnenemt des fenetres et hyper lourd sous macosx. c'est pour cette raison que j'ai appris a ne plus le faire :-)
en revanche as tu essaye d'activer quartz2dextreme car une fois active c'est le jour et la nuit, malheureusement cette fonctionnalite n'est pas conseillé par Apple sous Tiger il faut attendre MacosX 10.5.
Sinon OSX86 sur une intel 900 me semble carrement plus fluide pour redimensionner les fenetres rien a voir avec mon powerbook et sa radeon 9600.
[^]Re: Cher Père Noël...
Si vous vous intéressez de plus près au problème de la lenteur, vous pourrez sûrement vous rendre compte que le serveur X est particulièrement rapide et souffre parfois du fait d'être trop rapide !
Si vous avez des lenteurs ou des soucis d'affichage, prenez-vous en plutôt à la XLib qui est belle et bien une usine à gaz. Ajoutez à ça les bibliothèques graphiques qui n'utilisent pas toutes les optimisations de X et vous comprendrez bien mieux le soucis.
En effet, ce n'est seulement que depuis Qt 4 (pour les applications qui l'utilisent) que le "backing store" est utilisé (X se charge de redessiner lui-même la partie de fenêtre qui s'est découverte) alors que cette fonctionalité commence un peu à dater au niveau de X. Je ne crois pas que Gtk l'utilise.
la bibliothèque XLib ne peut être utilisé qu'en monothread ce qui signifie que les développeurs doivent s'adonner à des gymnastiques peu simples pour arriver à s'en servir dans le cas d'applications multithread. Il faudra attendre la sortie de la bibliothèque XCB / XCL pour palier ce défaut !
Moralité, méfions-nous des conclusions un peu trop hâtives, surtout dans les domaines comme celui-ci qui mettent en jeu beaucoup d'intervenants qui ont, eux aussi, leur part de responsabilité !
[^]Re: Cher Père Noël...
J'ai envie de rebondir sur ce commentaire pour apporter ma petite pierre personnelle à cette discussion.
J'entend très souvent des gens se plaindre de X, pour toutes sortes de raisons, généralement mauvaises. Aurélien me pardonnera d'utiliser aussi les remarques qu'il m'a faites sur IRC :)
Je vais tenter d'expliquer l'origine des remarques, et pourquoi elles sont infondées.
1. X est lent parce qu'il utilise le réseau, même en local.
(On la voit moins ces derniers temps, c'est vrai.)
Des sockets sont utilisés pour le dialogue entre les applications et le serveur X. Cela a porté certaines personnes à penser que retirer le support réseau de X permettrait une avancée en termes de vitesse, parce que le réseau est une couche inutile pour une utilisation en local.
Mais voilà : en local, X utilise les sockets UNIX, qui sont une des formes les plus rapides d'IPC sous linux. Keith Packard (vous savez, le type qui innove dans X depuis bien longtemps et qui veut que ce soit rapide) avait comparé l'utilisation des sockets UNIX avec celle de la mémoire partagée pour le dialogue applis-serveur. C'était sans appel...
2. X est lent parce qu'il dessine lentement.
Vous déplacez une fenêtre et celles qui se trouvent en dessous peinent à se mettre à jour, vous voyez des trainées. Vous en concluez que X est lent pour afficher un pixmap.
Pour voir si l'affichage d'un pixmap à l'écran est vraiment lent chez vous, je vous propose de lancer x11perf -copypixwin500, qui va afficher à l'écran un pixmap de 500x500 et mesurer le temps que ça prend. Chez moi, c'est environ 2000 affichages par seconde. Ce n'est donc pas ça qui est lent. Faites d'autres tests de x11perf pour vous convaincre, si nécessaire. Vous devriez en conclure que X est rapide. Très rapide.
3. Un serveur X par dessus OpenGL serait plus rapide
Peut-être un peu. On associe souvent (parfois inconsciemment) OpenGL et rapidité, et on oublie que ce n'est qu'une API, une manière d'attaquer le driver.
Par contre, c'est une API connue et maitrisée par de très nombreuses personnes et sensiblement identique pour tous les modèles de carte graphique, ce qui pourrait permettre un développement plus aisé. Faire du « Tout OpenGL » accélérera sans doute les effets spéciaux (transparence, déformation, exposé-like, ...), mais pas le reste. Ce qui sera accéléré par contre, c'est le développement sur une API connue.
4. X bouffe plein de RAM
Vous êtes gentiment connecté sur votre session X, et il vous vient tout à coup à l'idée de lancer un ps aux | grep X. Vous constatez alors que X utilise 285660 Ko, près de 280Mo. Woah !
Blâmez (si j'ose dire) votre soif d'avoir des applications ouvertes. Chaque application va demander au serveur X de lui allouer des pixmaps pour les fenêtres, les icones, les boutons, et plein d'autres choses. Tout ceci se retrouve compté pour X... Ajoutez à ça les zone de RAM vidéo qui sont mappées mais ne consomment pas de RAM système.
Vous pouvez faire le test très simplement (Note: Votre kilométrage peut varier, comme on dit.)
Toute instance de X étant fermée, faites un free -k dans une console et regardez la première valeur de la ligne +/- buffers/cache:. Elle vous indique la quantité de RAM réellement utilisée.
Dans une autre console, lancez juste X (pas startx ou xinit, juste X). Revenez sur la première console, relancez free -k et, ô miracle, X ne prend que 12 Mo ! Un examen attentif de la sortie de ps aux indique en outre que près de 10 Mo sont partagés. Pas très utile si vous n'avez qu'une session, mais intéressant pour ceux qui utilisent des terminaux distants. (Voir aussi le post de zero heure un peu plus bas.)
5. Le backing-store est la panacée, tout le monde doit l'utiliser
Ca commence à être possible, mais n'oubliez pas que si chaque fenêtre veut s'enregistrer dans le serveur X, le point 4 va recommencer à faire grincer des dents :)
Avec deux écrans, ma résolution est de 3648*1536, en 32bits. J'ai au strict minimum six bureaux remplis. Quantité de RAM nécessaire pour mettre tout ça en backing-store : 128Mo...
Le backing-store doit être utilisé là où il sera le plus utile, comme l'affichage d'images. Un mplayer ou une Konsole n'en ont pas besoin !
Mais alors pourquoi c'est lent ?
Principalement pour deux raisons.
La première, c'est que vos applications se redessinent lentement. Si je déplace une fenêtre à cheval sur le bureau (couleur unie), une konsole (fonte bitmap) et un konqueror, je n'ai des traînées qu'à un endroit : sur konqueror. Ici, le backing-store servirait bien.
La seconde raison, Aurélien l'a déjà évoquée : la xlib suce des huitres ! (mais non, c'est pas un troll)
Le protocole X est super, asynchrone, rapide... et la xlib est synchrone. Ça signifie que vos applis passent leur temps à attendre les réponses du serveur alors qu'elles pourraient s'en passer. Si ça se voit moins en local, c'est catastrophique dès que la latence grimpe un peu. XCB/XCL devraient permettre de corriger ce problème tout en gardant la compatibilité avec la xlib.
Je me permets une petite réflexion sous forme de questions pour terminer ce (trop) long post :
Pourquoi est-ce qu'à chaque troll sur Xorg (et avant lui, sur Xfree), ce sont les « mauvaises » critiques qui ressortent ?
Pourquoi personne ne s'étonne qu'il ne soit pas possible d'ajouter un écran à la volée, ou de passer d'un mode clone à un mode bureau étendu ?
Pourquoi faut il faire tant d'efforts pour brancher et configurer une tablette graphique ?
Pourquoi est-il tout simplement si complexe à configurer ?
[^]Re: Cher Père Noël...
On pourrait aussi prendre le problème dans l'autre sens :
Mais alors pourquoi est-ce rapide chez les autres (je pense notamment à Quartz) ?
Effectivement, je jongle avec deux xorg.conf, pour changer de mode il me faut copier le nouveau fichier à l'aide de sudo (donc mot de passe),
puis redémarrer le serveur X, donc toutes les applications l'utilisant : on a vu plus pratique...
[^]Re: Cher Père Noël...
Pour ça, tu peux spécifier plusieurs sections « ServerLayout » et utiliser l'option -layout au lancement de X.
Mais il faut toujours relancer X, tout ce que tu éviteras, ce sera la copie du xorg.conf.
[^]Re: Cher Père Noël...
Ben vi mais ça rejoint néanmoins la critique sur la difficulté de paramètrage du serveur.
A cela s'ajoute la couche driver proprio et leurs inombrables options qu'il faut, ou non, activer en fonction du hard et on se retrouve avec des problèmes toujours rigolos à résoudre.
[^]Re: Cher Père Noël...
En passant, est-il possible de faire migrer des applications X sur un autre serveur graphique à la volée ... ou que lorsque le serveur quitte, toutes les applications ne quittent pas.
J'aimerais bien.
La Roue du Temps
[^]Re: Cher Père Noël...
Pour le premier point... un peu. GDK propose une API pour ca, qui fonctionne tant que tu ne fais pas trop de bidouilles (j'avais patché xchat pour ca, bah ca crashait violemment a cause des widgets custom qu'il utilisait, ca a ptet changé). Voir gtk-demo, "Change display".
L'API est la: http://developer.gnome.org/doc/API/2.0/gdk/index.html
[^]Re: Cher Père Noël...
Je trouve que tu grattes du bon côté, en effet un des principaux problème dans la vitesse d'affichage, ce sont les applis et plus particulièrement les toolkits qu'elles utilisent. Lorsqu'une fenêtre a besoin d'être redessiner, c'est effectivement l'application à qui appartient cette fenêtre qui va devoir s'y coller. On s'aperçoit du problème lorsque l'on utilise un thème un peu lourd pour son toolkit préféré, ca devient parfois extrêmement lent. Il faut donc qu'une attention toute particulière soit portée sur les moteurs de thèmes utilisés par les toolkits.
Ensuite tu parles de l'ajout d'un écran à chaud, etc... Je suis tout à fait d'accord sur ce point aussi, j'aimerai bien changer ma config sans pour autant perdre toutes mes fenêtres. De ce point de vue, je suis sur qu'il y a des choses encore plus puissantes à mettre en oeuvre que ce que l'on peut trouver chez M$ ou Apple.
Il faut continuer de pousser dans ces directions, je pense sincèrement que X est sur la bonne voie, et même sur plusieurs ;)
[^]Re: Cher Père Noël...
Je sais aussi que c'est pour cela que quasiment systématiquement (comme au début de ce thread par exemple), lorsque quelqu'un veut "prouver" que X c'est pourri et lent, il prend Firefox comme exumple ou OOo. Ils auront peut-être plus de mal avec OOo 2 maintenant qu'il utilise à priori les toolkits natifs, qui fonctionnent (il faut l'avouer) mieux maintenant.
Les vrais problèmes sont connus depuis un moment :
- Xlib (solution XCB)
- config à chaud
- outil (et framework) convivial de configuration
- optimisation de certains éléments
J'espère fortement que la modularisation de X va permettre plus facilement de régler ces problèmes.
Je trouve XOrg BEAUCOUP plus accessible maintenant, avec mes 220+ paquetages, qu'avant.
[^]Re: Cher Père Noël...
Un serveur X par dessus OpenGL serait plus rapide
Peut-être un peu. On associe souvent (parfois inconsciemment) OpenGL et rapidité, et on oublie que ce n'est qu'une API, une manière d'attaquer le driver.
D'après les vidéos des démos de XGL (le serveur X au-dessus d'OpenGL) le déplacement des fenêtres sont bigrement plus rapides :
http://vizzzion.org/stuff/xgl_wanking.avi
http://www.gnome.org/%7Eseth/blog-images/monkey-hoot/mpeg4/W(...)
Ce qui parait logique car d'après Jon Smirl ancien développeur de XGL/XEGL « la 3D est simplement plus rapide que la 2D, personne ne rend ses fonctions 2D plus rapides, toute la technologie silicium entre dans la 3D ». Toujours d'après Jon Smirl : « Dans certains cas ces nouveaux bureaux accélérés (par le GPU) peuvent s'afficher plus de cent fois plus rapidement que sur un ancien modèle. »
Xgl se sert aussi d'une nouvelle fonctionnalité d'OpenGL, les objets framebuffer (FBO) qui pour une application a l'apparence d'une fenêtre de dessin normale. Mais pour le gestionnaire de fenêtres, les fenêtres ressemblent à des textures et peuvent être manipulées avec des commandes de dessin normales comme le multitexture. Un gestionnaire de fenêtres basé sur OpenGL comme Luminosity peut combiner des fenêtres en utilisant un z-buffer et supprimer les limites de l'ordre Z strictement 2D et transformer une fenêtre en vague et à plusieurs reprises entrecroiser une autre fenêtre.
L'intérêt d'avoir un serveur X basée sur OpenGL et aussi de n'avoir qu'un seul pilote à maintenir au lieu des pilotes XAA, OpenGL à maintenir. Sans compter sur les nouveaux pilotes EXA.
X.org a choisi une solution à court terme en implémentant le sparadrap EXA repoussant ainsi la sortie du prometteur XGL de deux années. EXA/Render est uniquement un sous-ensemble de l'API générique OpenGL Mesa et risque d'être engraissé de nouvelles fonctionnalités, alors qu'avec OpenGL il est possible d'avoir une seule API pour tout.
[+] [^]Re: Cher Père Noël...
Je suis pas du tout d'accord avec cet argument !! Au contraire, je vois que X laisse des trainée, j'en conclus que X est lent, point !
Je me rappelle d'un test que j'avais fait à la sortie de Mozilla (les premières versions il y a longtemps). Le chargement d'une grosse page prenait quelques secondes de moins sous Mozilla que sous IE (genre 4s au lieu de 7s). Mais Mozilla donnait tout de même l'impression d'être beaucoup plus long, car il ne commençait à afficher qu'au chargement complet de la page.
Conclusion : il ne faut pas confondre performances brutes et impression de performance, c'est à dire la perception qu'a effectivement l'utilisateur des performances de sa machine.
Le numéro que vous avez composé est imaginaire.
Veuillez tourner votre téléphone de 90 degrés et recomposer.
[^]Re: Cher Père Noël...
Permet-moi de reprendre ton argument Mozilla pour suivre ton raisonnement.
Voilà ma question : Que fallait-il changer à X pour que Mozilla affiche l'image plus vite ?
La réponse est évidente : X n'est pas en cause (ou très peu), il fallait changer l'application.
C'est pareil pour une fenêtre qui doit se redessiner quand une partie devient visible. Si l'application ne redessine pas sa fenêtre, tu as des traînées.
Et quand je dis « changer l'application, » je parle aussi de la xlib, qui implique toute une série de round-trips inutiles entre X, le WM et l'appli.
Les applications dont l'affichage est principalement statique (du point de vue de l'ordinateur : un navigateur change souvent de page et scrolle, mais reste immobile pendant de loooooongs moments pour le CPU) ont tout intérêt à utiliser une fonctionnalité que X offre depuis des années, le backing-store.
[^]Re: Cher Père Noël...
D'accord avec toi, l'application Mozilla était en question et offrait une mauvaise expérience à l'utilisateur là où ses performances brutes étaient meilleures, c'est pour ça que la justification benchmark ne tient pas pour moi. Benchmark de quoi? D'un aspect précis de l'application qui ne rend pas compte de son comportement global.
D'ailleurs le test c'était IE vs Mozilla (vs Opera vs Netscape) donc sous Windows :)
La xlib, elle peut faire tant de round-trips qu'elle veut, ca n'empeche pas de faire du double buffering (effacement + nouvel affichage dans une mémoire offscreen avant d'afficher quoi que ce soit) alors pourquoi on n'en a toujours pas, toolkits / WM foireux ?
Il me semble pas avoir déjà vu un affichage sans trainées sous X, c'est mieux sous les WM légers (style FVWM) parce que les décorations étaient plus légères, mais il y a des trainées quand même.
En enfin c'est certainement pas aux développeurs d'applications de gérer leur rafraichissement, sinon on est pas prêt de voir un affichage fluide !
Le numéro que vous avez composé est imaginaire.
Veuillez tourner votre téléphone de 90 degrés et recomposer.
[^]Re: Cher Père Noël...
Toolkits qui ne tirent pas profit du backing-store.
Décorations légères ou non, c'est le WM qui est chargé de dire aux applications quand elles doivent se redessiner. Il est donc évident que son rôle est important.
Ben non, c'est le toolkit qui s'en charge.
[^]Re: Cher Père Noël...
6. C'est la faute du window manager
Oui, quand j'utilisais Ion3 le déplacement des fenêtres et la transparence étaient super rapides pour la simple raison qu'il n'y en pas!
Les fenêtres ne se superposent pas et les déplacements reviennent à échanger la position entre deux fenêtres. Bref c'est simple, pratique, rapide.
Seulement les applis sont mal intégrés et réagissent mal si on les privent de leur desktop préférée. Donc je suis revenu sous kwin et ça ramouille
Bref c'est la faute aux applis qui m'empêchent d'utiliser Ion3 confortablement..
[^]Re: Cher Père Noël...
Merci pour toute ces explications (pertinenté).
LA réponse qui manque, a ton avis, quand est-ce que XCB/XCL sera utilisé par les applications et que composite sera utilisable? D'apres toi?
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
[^]Re: Cher Père Noël...
XCL? Jamais. Ça a été abandonné.
XCB? Peut être dans la prochaine version 7.1 :) Il y a déjà eu une tentative de congélation d'api ce mois-ci, mais 15 secondes après le développeur a dit "bon peut être pas après tout". Maintenant, ils modifient juste un peu le comportement des retours d'erreurs.
Et comme ça fait un bon moment que xlib peut être compilé par dessus xcb...
[^]Re: Cher Père Noël...
À propos de X et de la mémoire qu'il occupe, il y a un outil extrêmement pratique qui s'appelle xrestop. Il est certainement disponible parmi les paquets de n'importe quelle bonne distribution.
Grâce à xrestop, je me rends compte que sur cette news, Mozilla bouffe à lui tout seul 23 Mo de pixmaps et autres joyeuseries.
[^]Re: Cher Père Noël...
Tu pourrais citer tes sources :)
http://primates.ximian.com/~federico/news-2005-11.html#24
[^]Re: Cher Père Noël...
Deux questions relatives a ca:[^]Re: Cher Père Noël...
intéressant.
Il y a également cette page très complète sur le sujet :
http://www.freedesktop.org/~jonsmirl/graphics.html
You can't grep dead trees...
[^]Re: Cher Père Noël...
Complète certes, mais très orienté sur le sujet des performances (EXA Vs XGL à la sauce Smirl).
[^]Re: Cher Père Noël...
Q. Why does X use so much memory?
A. When measuring any application's memory usage, you must be careful to distinguish between physical system RAM used and virtual mappings of shared resources. For example, most shared libraries exist only once in physical memory but are mapped into multiple processes. This memory should only be counted once when computing total memory usage. In the same way, the video memory on a graphics card or register memory on any device can be mapped into multiple processes. These mappings do not consume normal system RAM.
This has been a frequently discussed topic on XFree86 mailing lists; see, for example: http://marc.theaimsgroup.com/?l=xfree-xpert&m=9683576711(...)
The 'pmap' utility described in the above thread is available here: http://web.hexapodia.org/~adi/pmap.c and is a useful tool in distinguishing between types of memory mappings. For example, while 'top' may indicate that X is using several hundred MB of memory, the last line of output from pmap:
mapped: 287020 KB writable/private: 9932 KB shared: 264656 KB
reveals that X is really only using roughly 10MB of system RAM (the "writable/private" value).
RESUME FRANCOPHONE:
En clair, ne te fie pas a top. top indique une consommation memoire fausse pour X car elle compte aussi celle des bibliotheques partagees (par X avec d'autres programmes). Et y'a pas que ca. Utilise pmap [pid de X] pour voir la consommation exacte de X. pmap est maintenant installe sur beaucoup de systemes. Note que c'est valable pour tout programme.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: Cher Père Noël...
Quite à faire un doublon, plutot que de mettre un plus, je le dit en clair : ce commentaire est très interressant. Notez bien que ça s'applique à plein d'applications.
Ceux qui connaissent unix, et les différences subtiles entre les valeurs de sar, vmstat, top et ps auront forcément un jour essayer de gratter la suface pour savoir ce que mémoire occupée veut dire... un chiffre est loin de tout résumer, très loin, il faut connaitre la partie partagée, la partie heap, stack, etc...
Il faut aussi savoir que sur les système unix, le but n'est pas d'économiser la mémoire RAM (tant qu'il y en a) mais plutôt de la préferer aux autres formes de mémoire virtuelle, comme le swap, qui lui est, comment dire, un peu plus lent. Hm. Je me demande si ça change grand chose au problème, cela dit...
Linux ou Windows ? La liberté du loup ou le collier du chien ?
[^]Re: Cher Père Noël...
Ca change que lorsque j'atteint un certain nombre d'appli ouverte (2 Konsole, 1 Firefox, 1 Thunder, 1 OOo, 1 konqueror), je mange sur le swap.
Bon là c'est pas grave.
Mais quand je veux démarrer Warcraft, je suis obligé de virer les 3 plus gros (ff, thunder et OOo) au minimum. Avec 512 Mo de mémoire je pensais être un minimum à l'abris. Mais non...
Ca existe des utiltaires pour défragmenter la mémoire ?
[^]Re: Cher Père Noël...
Perso je place un cedega+wow et ff ou un cedega+wow et OO2 sans problème.
(athlon xp 2000+, 7xxMo ram, Geforce 4600ti 120Mo, Xorg 6.8, fluxbox 4 bureaux virtuels)
Ce commentaire est :
Génial, Nul, 42
[+] [^]Re: Cher Père Noël...
Alors je suis plutot d'accord avec toi et j'aime pas trop le serveur X. Je pense qu'un serveur X rootless optionel comme dans mac os x c'est mieux, apres tout pourquoi s'encombré d'un système client serveur quand tout est en local ?
Mais surtout bon il ne faut pas critiquer le sujet de l'article dans le premier commentaire sans quoi c'est toujour moinsage a gogo, le 3eme ou 4eme commentaire est une meilleure solution ou mieux en répondant a un autre.
[^]Re: Cher Père Noël...
Toi tu utilises peut-être tout en local; mais ce n'est pas le cas de tout le monde.
Avec linux, on peut installer une solide machine pour lancer tout un tas de programmes récents (OpenOffice, Mozilla, Evolution...) et brancher dessus deux douzaines de postes obsolètes en XDMCP. Ca permet à beaucoup d'associations d'installer des postes à faible coût, ça permet aux pays moins occidentaux de faire quelque chose de nos déchets informatiques dont on les abreuve généreusement pour réduire leur fracture numérique, ça permet de dépanner à distance un ami ou un client qui a un problème, ça permet de conserver son bureau et d'y accéder de partout, de travailler à distance sur son ordinateur.
Et quand tout est en local, il y a les extensions de mémoire partagée et les sockets qui évitent tout le coût des piles TCP/IP.
Le système client serveur, c'est toute la force d'Unix. Loin d'être encombrant, c'est une conception qui est toujours d'actualité. A tel point que microsoft l'a copié avec son terminal server.
[^]Re: Cher Père Noël...
C'est gentil de m'apprendre a quoi sert le client serveur. Je veut bien que x.org ne soit pas lourd et que ces 600 Mo de code source ça soit de la décoration mais il se trouve que linux accumule quand meme un certain retard par rapport aux concurents au niveau fonctionalités du coté interface graphique (3d,transparence) . Il se trouve aussi qu'on peut faire du client serveur sur mac os x et sous windows comme tu le dit toi meme, la diférence c'est que c'est pas obligatoire. Mais j'ai l'impression qu'ici critiquer le serveur X c'est interdit alors éclatez vous moinsez c'est offert.
[^]Re: Cher Père Noël...
Critiquer le serveur X est tout a fait ton droit. Mais il est aussi de notre droit de t'envoyer balader quand tu répete une connerie à laquelle on a déjà répondu 100 fois. (dont plusieurs sur cette page)
Donc je le dit une dernière fois : "La couche reseau de X ne le ralentit pas dans le cas d'une utilisation locale."
Alors pourquoi virer cette couche qui est si pratique dans pas mal de cas, pour ne rien gagner dans les cas ou elle n'est pas utile ?
La seule chose que ça changerait, c'est qu'il faudrait que pas mal de developeurs ce mettent à bosser la dessus pour l'enlever proprement, et ensuite passer un long moment à tester tout ça... et pendant ce temps on ne developpe pas grand chose d'autre, du style les killer feature que tu desire tant : transparence et autres...
Perso je préfère qu'ils bossent a rendre la xlib asynchrone, là au moins le résultat sera visible, tout le monde en porfitera. Le seul point négatif, c'est que la couche reseau sera toujours la et il faudra donc regulierement rééxpliquer qu'elle ne ralentit pas un ordi en local.
[^]Virer non mais amméliorer serait utile
Personellement j'appécie qu'on puisse travailler en distant avec X, mais NX arrive à obtenir des performances bien meilleures en distant, apparemment en cachant mieux les pixmap et en diminuant le nombre de RTT fait.
Plutôt que d'avoir X | NX | un toolkit, je me demande s'il ne serait pas plus efficace d'intégrer NX dans tout ça, plutôt que d'avoir une couche intermédiaire en plus.
[^]Re: Virer non mais amméliorer serait utile
et en diminuant le nombre de RTT fait.
ouais, bah tu peux etre sur que la sncf va se mettre en greve par solidarite avec le serveur qui en arrive a travailler parfois 24H00 par jour, alors si en plus on lui enleve des rtt...
[^]Re: Cher Père Noël...
Avec un serveur X traditionnel, tu peux très bien faire des fenêtres en 3D. Cf ma signature :)