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.
Aller plus loin
- L'annonce officielle (7 clics)
- Le site de Xorg (8 clics)
- Les Release Notes (7 clics)
# Cher Père Noël...
Posté par Ontologia (site web personnel) . Évalué à 1.
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...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par freeze . Évalué à 4.
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...
Posté par Ontologia (site web personnel) . Évalué à 10.
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...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par Ontologia (site web personnel) . Évalué à 7.
Ouuuuuhh le lapsus !!
Falloir que j'en parle à mon psychiatre !
Je voulais dire "unique", bien sûr !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par Bruno Adele (site web personnel) . Évalué à -3.
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...
Posté par Ontologia (site web personnel) . Évalué à 1.
Donc j'en conclu que je ne me trompe pas de cible.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par Pinaraf . Évalué à 7.
Ç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...
Posté par Ontologia (site web personnel) . Évalué à 1.
NVIDIA/ATI vont pas s'amuser à développer deux circuit de gestion de la transparence (?)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par Pinaraf . Évalué à 3.
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...
Posté par Westy . Évalué à 6.
[^] # Re: Cher Père Noël...
Posté par Yann012 . Évalué à 2.
[^] # Re: Cher Père Noël...
Posté par Anonyme . Évalué à 10.
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...
Posté par Ontologia (site web personnel) . Évalué à 0.
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par GEDsismik (site web personnel) . Évalué à 1.
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...
Posté par mickabouille . Évalué à 4.
> 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...
Posté par MsK` . Évalué à 6.
Chez moi X bouffe dans les 30-40 Mo de ram.
[^] # Re: Cher Père Noël...
Posté par Arnaud . Évalué à 8.
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...
Posté par MsK` . Évalué à 9.
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 )
[^] # Re: Cher Père Noël...
Posté par Anonyme . Évalué à 4.
[^] # Re: Cher Père Noël...
Posté par MsK` . Évalué à 3.
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 :)
[^] # Re: Cher Père Noël...
Posté par billiob . Évalué à 6.
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...
Posté par Pinaraf . Évalué à 5.
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...
Posté par ookaze . Évalué à 4.
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...
Posté par krumtrash . Évalué à 3.
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...
Posté par PierreLrq . Évalué à 3.
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...
Posté par Amand Tihon (site web personnel) . Évalué à 3.
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...
Posté par MsK` . Évalué à 2.
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
[^] # Re: Cher Père Noël...
Posté par portanoo92 . Évalué à 10.
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...
Posté par serge_kara . Évalué à 3.
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...
Posté par ナイコ (site web personnel) . Évalué à 5.
Euhhh, et "Kompose" ? Sur Mandriva, en utilisant les sources "contrib" :
# urpmi Kompose
Et c'est vrai que c'est pratique.
[^] # Re: Cher Père Noël...
Posté par Ontologia (site web personnel) . Évalué à 4.
Mais sinon c'est assez génial comme jouet, bien que ça n'arrive pas àa cheville de celui d'Apple.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par Mildred (site web personnel) . Évalué à 3.
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,
[^] # Re: Cher Père Noël...
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: Cher Père Noël...
Posté par Nicolas Blanco (site web personnel) . Évalué à 10.
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...
Posté par Ontologia (site web personnel) . Évalué à 1.
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)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par naibed . Évalué à 10.
[^] # Re: Cher Père Noël...
Posté par reno . Évalué à 2.
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...
Posté par portanoo92 . Évalué à 7.
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...
Posté par ldng . Évalué à 2.
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...
Posté par briaeros007 . Évalué à 2.
de xorg ou de xlib/wm/toolkit ?
[^] # Re: Cher Père Noël...
Posté par cortex62 . Évalué à 8.
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é.
[^] # Re: Cher Père Noël...
Posté par kursus_hc . Évalué à 3.
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...
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
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...
Posté par serge_kara . Évalué à 3.
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...
Posté par cortex62 . Évalué à 3.
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).
[^] # Re: Cher Père Noël...
Posté par serge_kara . Évalué à 2.
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...
Posté par portanoo92 . Évalué à 0.
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...
Posté par serge_kara . Évalué à 5.
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...
Posté par portanoo92 . Évalué à 1.
[^] # Re: Cher Père Noël...
Posté par Mildred (site web personnel) . Évalué à 1.
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)
[^] # Re: Cher Père Noël...
Posté par Moonz . Évalué à 2.
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...
Posté par serge_kara . Évalué à 2.
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...
Posté par portanoo92 . Évalué à 1.
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...
Posté par Aurélien Croc (site web personnel) . Évalué à 10.
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...
Posté par Amand Tihon (site web personnel) . Évalué à 10.
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...
Posté par Pierre6020 . Évalué à 0.
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...
Posté par Amand Tihon (site web personnel) . Évalué à 6.
Mais il faut toujours relancer X, tout ce que tu éviteras, ce sera la copie du xorg.conf.
[^] # Re: Cher Père Noël...
Posté par tuiu pol . Évalué à 1.
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...
Posté par Mildred (site web personnel) . Évalué à 1.
J'aimerais bien.
[^] # Re: Cher Père Noël...
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
L'API est la: http://developer.gnome.org/doc/API/2.0/gdk/index.html
[^] # Re: Cher Père Noël...
Posté par Jésus Christ . Évalué à 3.
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...
Posté par ookaze . Évalué à 5.
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...
Posté par Bruno Ethvignot (site web personnel) . Évalué à 10.
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...
Posté par Jean-Marc (site web personnel) . Évalué à -3.
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.
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . Évalué à 4.
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...
Posté par Jean-Marc (site web personnel) . Évalué à 1.
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 !
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . Évalué à 4.
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...
Posté par alice . Évalué à 1.
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...
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
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?
[^] # Re: Cher Père Noël...
Posté par mickabouille . Évalué à 4.
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...
Posté par kd . Évalué à 3.
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...
Posté par ldng . Évalué à 0.
http://primates.ximian.com/~federico/news-2005-11.html#24
[^] # Re: Cher Père Noël...
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
[^] # Re: Cher Père Noël...
Posté par B16F4RV4RD1N . Évalué à 3.
Il y a également cette page très complète sur le sujet :
http://www.freedesktop.org/~jonsmirl/graphics.html
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Cher Père Noël...
Posté par Jean Roc Morreale . Évalué à 2.
[^] # Re: Cher Père Noël...
Posté par ZeroHeure . Évalué à 7.
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.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Cher Père Noël...
Posté par Valdenaire Denis (site web personnel) . Évalué à 4.
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...
[^] # Re: Cher Père Noël...
Posté par Ontologia (site web personnel) . Évalué à 2.
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 ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cher Père Noël...
Posté par Calim' Héros (site web personnel) . Évalué à 2.
(athlon xp 2000+, 7xxMo ram, Geforce 4600ti 120Mo, Xorg 6.8, fluxbox 4 bureaux virtuels)
[^] # Re: Cher Père Noël...
Posté par wahnby . Évalué à -6.
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...
Posté par Sébastien Koechlin . Évalué à 4.
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...
Posté par wahnby . Évalué à 0.
[^] # Re: Cher Père Noël...
Posté par beagf (site web personnel) . Évalué à 8.
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
Posté par reno . Évalué à 1.
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
Posté par serge_kara . Évalué à 6.
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...
Posté par Pinaraf . Évalué à 3.
# fausse joie ?
Posté par isydor . Évalué à 2.
"hardware 3D acceleration (except R300 and R400 series cards)"
http://ftp.x.org/pub/X11R7.0/doc/html/radeon.4.html
[^] # Re: fausse joie ?
Posté par mickabouille . Évalué à 2.
[^] # Re: fausse joie ?
Posté par Cyril . Évalué à 2.
[^] # Re: fausse joie ?
Posté par lesensei . Évalué à 2.
Cela dit, sur Ubuntu Dapper, un "Xorg -version" indique que je suis en X11R7-rc4, glxinfo indique que le Direct Rendering est activé et qu'un certain nombre d'extensions GLX sont comprises par le driver. Un léger test avec divers programmes utilisant la 3D semble indiquer que c'est effectivement le cas (mais glxgears ne me donne pas de chiffre, l'état expérimental du driver en est probablement la cause).
Cela dit, vu que Dapper inclut de nombreuses choses expérimentales (genre le driver pour les chipsets wireless b/g broadcom, malgré les conseils des devs), ça ne me surprendrait pas qu'ils aient ajouté un patch reprenant ça du CVS, même si je n'en trouve pas trace dans les changelogs (il y en a tellement pour les paquets Xorg que je ne saurais dire si j'ai bien cherché où il fallait...).
[^] # Re: fausse joie ?
Posté par Pinaraf . Évalué à 4.
glxgears -printfps
Parce que les FPS de glxgears c'est pas un benchmark, donc il faut décourager les gens...
[^] # Re: fausse joie ?
Posté par nicodache . Évalué à 4.
d'un autre coté, c'est plutot efficace pour tester ton accélération 3D.
si t'as 300FPS, tu remercies le processeur.
SI t'en a 3000, tu remercies la carte graphique et le dri ;)
[^] # Re: fausse joie ?
Posté par Guillaume D. . Évalué à 1.
J'ai 325 FPS sans DRI et 354 avec sur une i855GL, alors glxgears ....
Fait un test avec trocs, et la tu vois dessuite la diff !
A+
[^] # Re: fausse joie ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: fausse joie ?
Posté par cortex62 . Évalué à 2.
J' ai fait l' essai avec celestia, il est devenu parfaitement fluide, au moins comparable à une geforce 256 ou DDR (première génération).
Pour torcs j' hésite un peut quand même il me semble nettement plus lourd (sur un RV100, je vais voir en R200).
[^] # Re: fausse joie ?
Posté par iug . Évalué à 1.
[^] # Re: fausse joie ?
Posté par nicodache . Évalué à 2.
quant à la divulgation des sources, c'est du même domaine que la non-divulgation des spécifications, les concurrents pourraient étudier les sources (ou les specs) et s'en inspirer pour leurs produits...
En diffusant leurs drivers sous GPL, ils pourraient s'assurer de la non-utilisation secrete par nVidia/SIS/XGI/Matrox/autre, et donc affûter leurs avocats dès le moment ou nVidia publierait un bout du driver repompé des leurs, mais ils ne pourraient pas garder la main mise sur les sources. Et ca ne semble pas leur convenir ;)
# Killer feature
Posté par Victor STINNER (site web personnel) . Évalué à 6.
(en français : Support des souris de plu de 12 boutons dans le pilote souris de base)
Super, je vais enfin pouvoir brancher ma souris sans boule mais avec 105 touches :-D
Haypo
PS: Plus sérieusement, vous avez une photo de ce genre de monstre ?
[^] # Re: Killer feature
Posté par Olivier Samyn (site web personnel) . Évalué à 4.
http://www.logitech.com/index.cfm/products/productlist/BE/FR(...)
Sur ma souris, y'a par exemple 10 boutons:
- Btn gauche, droit
- Molette + click sur la molette ( = 3 boutons)
- La molette peut basculer de gauche à droite (en plus de la rotation) => 2 boutons supplémentaires
- Un p'tit bouton derrière la molette
- 2 boutons à hauteur du pouce
=> 10 boutons
[^] # Re: Killer feature
Posté par Ontologia (site web personnel) . Évalué à 8.
Ok je ---> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Killer feature
Posté par Axys . Évalué à 1.
D'ailleur, à propos de cette souris, sous linux le curseur ne se déplace pas de manière très fluide... Lors de grands mouvements, aucun problème, mais lorsque que j'ai besoin de précision (par exemple, du dessin au pixel sous Gimp), c'est assez génant... je possède une mx500 qui n'a pas ce problème... une idée d'où ça peut venir?
[^] # Re: Killer feature
Posté par fenril . Évalué à 0.
google est ton ami.
Le problème, pour moi n'est pas la fluidité mais qu'une fois sur deux, elle est sur un /dev/input/eventX différent. Mais le fait d'utiliser une distrib en phase de développement n'aide pas beaucoup. :)
[^] # Re: Killer feature
Posté par Amand Tihon (site web personnel) . Évalué à 4.
Tu trouveras une manière de faire sur http://floam.sh.nu/index.xhtml?page=guides§ion=mx100(...) par exemple.
Ma configuration est très légèrement différente :
Il ne reste plus qu'à spécifier le nom du périphérique dans ton xorg.conf.
# ptite faute
Posté par Achille Fouilleul (site web personnel) . Évalué à 2.
# Compilation
Posté par naibed . Évalué à 2.
# rotation d'écran ?
Posté par Sol_Bianca . Évalué à 1.
je parle de la rotation via xrandr.
[^] # Re: rotation d'écran ?
Posté par Infernal Quack (site web personnel) . Évalué à 4.
Sous nVidia chez moi ça marche
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: rotation d'écran ?
Posté par Sol_Bianca . Évalué à 1.
j'ai une i855GM, dans un vaio u71p.
si je veux de la rotation d'écran, il faut modifier xorg.conf pour faire soit du 800x600 soit du 600x800 et donc redémarrer à chaque fois X.
merci quand-même.
# Cairo and co...
Posté par sylware . Évalué à 1.
[^] # Re: Cairo and co...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
[^] # Re: Cairo and co...
Posté par Amand Tihon (site web personnel) . Évalué à 6.
xmoto est injouable sur mon portable (driver vesa). Bouger la souris dans le menu est déjà une gageure.
Voyons ce que dit glxinfo :
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
Mais si je le ssh depuis ma machine de bureau qui a une nvidia et ses drivers propriétaires, je peux jouer sans le moindre problème, c'est fluide.
Je n'ai bien sûr toujours pas de Direct Rendering dans ce cas, mais glxinfo me signale malgré tout ceci d'intéressant :
direct rendering: No
server glx vendor string: NVIDIA Corporation
server glx version string: 1.3
Et crois-moi, c'est accéléré.
Ça m'avait vachement surpris la première fois. Je montrais l'utilisation de X/ssh à un ami windowsien puis j'ai du dire quelque chose comme « évidemment, pour les trucs en 3D, ça marche pas. » J'ai voulu prouver mes dires, et on était tous les deux sur le cul...
[^] # Re: Cairo and co...
Posté par Al Brow . Évalué à 3.
C'est un peu du ping pông mais en gros, le code de l'appli tourne en dessous du X du portable et les deux serveurs X (le portable et le desktop ) se transmette uniquement des actions (bouge fenetre, dessine un objet 3D).
Si tu veux faire tourner des applis encore plus rapidement , NX se place entre les deux X et "compresse" les commandes, les dessins ... .
Moi j'ai été bluffé par la puissance de NX (un bureau kde passe sans lags dans un connecion rtc 56k )
Si tu es curieux tu peux creuser le pourquoi nvidia fait toujours des drivers à la mode utah glx .... et trouver le driver libre qu'ils avaient donné à la communauté dans l'espoir qu'on les aide (les drivers DRI sont très complexe mais apporte une stabilité clé en main).
[^] # Re: Cairo and co...
Posté par sylware . Évalué à 1.
# radeon et composite
Posté par MMM . Évalué à 3.
[^] # Re: radeon et composite
Posté par portanoo92 . Évalué à 2.
ce qui me fait penser a une chose.
Actuellement il etait plus interessant de prendre une carte nvidia si l'on voulait uiliser composite, ou pour son "support" linux.
Mais avec le driver pour 9200 qui fonctionne visibelemnt tres bien et la prochaine arrivee du driver libre r300 avec une bonne gestion du DRI je me demande si on ne va pas arriver à l'inverse de maniere radicale.
Car je n'ai pas entendu parler d'un driver libre pour la nvidia.
Alors si nvidia decide de ne pas utilise EXA sur ses prochains pilotes nvidia alors on est pas dans la mouise.
Ca me fait penser que je vais finalement peut-être me prendre un ibook G4 moi lorsque tout le monde voudra s'en debarrasser pour un intel nous on pourra l'utiliser sans pb sous linux meme l'airport qui semble plus ou moins utilisable.
[^] # Re: radeon et composite
Posté par MMM . Évalué à 3.
[^] # Re: radeon et composite
Posté par mickabouille . Évalué à 2.
Par contre, peut être l'intégreront-ils au pilote nv...
[^] # Re: radeon et composite
Posté par Pinaraf . Évalué à 3.
http://wiki.x.org/wiki/ExaStatus
[^] # Re: radeon et composite
Posté par Pinaraf . Évalué à 2.
Actuellement, ils n'utilisent pas EXA, mais ils n'utilisent pas non plus XAA !
Ils ont leur propre architecture d'accélération, qui permet déjà d'accélérer Render. Mais cette accélération est moins fiable et moins bonne que EXA. La prochaine version du driver nVidia devrait apporter une accélération bien meilleure, mais ça reste à confirmer.
De plus, EXA ne change toujours pas un problème avec Composite activé : l'OpenGL ne marche pas, sauf dans les drivers nVidia si on active la bonne option !
[^] # Re: radeon et composite
Posté par portanoo92 . Évalué à 1.
[^] # Re: radeon et composite
Posté par agmk . Évalué à 1.
Option "AllowGLXWithComposite" "Enable"
Sur une NVidia.
[^] # Re: radeon et composite
Posté par serge_kara . Évalué à 3.
a mettre dans la section device de ta carte graphique.
Tres important : il est impossible d'utiliser OpenGL avec composite active sur une nvidia.
Ca fait planter X direct.
Exit les jeux, ca encore ca peut aller, exit les screensaver opengl (et ca c'est beaucoup plus vicieux, on n'y pense pas forcement..)
Perso, j'ai fait des tests hier soir.
Les ombres, c'est classe, ca fait vraiment plaisir de les avoir.
Quelques problemes d'integration avec Gnome sous ubuntu qui m'empechent de l'utiliser :
- Impossiblite d'utiliser opengl, comme indique ci dessus.
- la fenetre de deconnexion n'apparait plus... gros bug quoi.
- bug d'affichage dans ff : la toolbar dlfp laisse des traces d'affichages quand on defile la page vers le bas.
- Un panel place en haut de l'ecran porte une ombre sous lui, ce qui est bizarre visuellement.
- tres chiant a configurer si on n'installe pas gcompmgr, qui n'existe pas dans ubuntu et que j'ai trouve au detour d'un forum ubuntu (pas d'url, desole.. google est votre ami). Il permet notamment de gerer le probleme du gnome panel : si xcompmgr est lance apres le panel, les fenetres le recouvriront... moyen, il faut donc lancer xcomp, tuer gnome panel qui se relance tout seul et paf ca marche. gcompmgr permet de gerer tout ca et de l'appliquer par defaut a la session, c'est cool.
- La transparence doit pour l'instant etre activee a chaque session avec transset alpha + clic sur la fenetre.. Trop lourd.
Mais comme je l'ai dit plus haut, la transparence, bah c'est un peu gimmick quand meme.
- Si on veut lancer xcomp au demarrage via l'utilitaire de gnome, il faut lui donner une priorite au demarrage bizarre (41 je crois), sinon ca fait planter le demarrage. Regle aussi par l'utilisation de gcompmgr.
J'avais essaye sous kubuntu, avec la meme machine, c'est encore mechamment bugge (les fenetres laissent des traces partout, c'est affreux), faudra attendre un peu plus pour l'avoir. Par contre, le truc bein c'est que kde permet de definir les proprietes de transparence des fenetres, choses encore impossible avec gnome.
Bref, en gros ca marche, maintenant il faut peaufiner et ca sera la mega classe.
[^] # Re: radeon et composite
Posté par Meku (site web personnel) . Évalué à 2.
Ca fait planter X direct.
Ça doit dépendre du matériel, ou de je ne sais quoi, mais chez moi ça fonctionne sans planter... (testé sur 3 machines différentes équipées de trois cartes nvidia différentes).
Par contre je suis tout à fait d'accord avec les points cités en dessous... Composite perd tout son intérêt à cause de petits problèmes comme ça, qui sont finalement très chiants.
[^] # Re: radeon et composite
Posté par serge_kara . Évalué à 2.
il me semblait avoir lu dans la doc que cela ne pouvait pas marcher, et que l'option glxwithcomposite etaient la vraiment pour ceux qui voulaient vraiment forcer la chose a leurs risques et perils.
Il me semble avoir fait marcher la chose avec le pilote nv.
Mais v'la les perfs... Encore moins utilisable.
[^] # Re: radeon et composite
Posté par Meku (site web personnel) . Évalué à 1.
[^] # Re: radeon et composite
Posté par ookaze . Évalué à 1.
Ca fait planter X direct.
Ca n'est pas vrai. Ca c'est le comportement sans mettre l'option que tu donnes.
Si tu l'actives, ça fonctionne, mais c'est instable, et peut emporter ton serveur X (et les périphs qu'il contrôle comme le clavier) avec lui.
On nous parle toujours de l'impossibilité de mélanger Composite et OpenGL, mais j'aimerais savoir si c'est à cause de l'implémentation ou des architectures (plus grave).
[^] # Re: radeon et composite
Posté par serge_kara . Évalué à 2.
il me semble l'avoir fait marcher avec le pilote nv, mais les perfs sont mauvaises.
c'est pour ca que j'ai precise "sur une nvidia".
Le "avec le pilote nvidia" me paraissait implicite, mais apparement ca n'est pas le cas, desole.
[^] # Re: radeon et composite
Posté par ookaze . Évalué à 1.
Effectivement, avec nv, c'est très lent.
[^] # Re: radeon et composite
Posté par melalcoolique . Évalué à 2.
http://www.ubuntuforums.org/showthread.php?t=75527
A lire tout particulièrement le début ou l'auteur explique comment installer gcompmgr (utile mais pas indispensable néanmoins).
A titre personnel, j'utilise le module EXA avec les drivers Xorg 7.0rc4 et il est vrai que les performances sont excellentes avec une ATI 9200 même si il subsiste des "petits" problèmes comme mentionné plus haut. La plus dommageable étant la désactivation de l'accélération 3D et la présence de quelques artefacts ici et là.
Une petite question maintenant concernant Xlib et XCB, à quelle échéance peut-on espérer voir arriver le développement final de XCB. Lors de la sortie de Xorg 7.1 ?
Est ce que toutes les cartes en profiteront quelque soit les drivers?
PS: quel dommage que Novell travaille dans son coin sur XGL, on peut se demander si leurs travaux profiteront à la communauté et apparemment personne n'a de certitude la dessus...
Lire l'article de Aaron Seigo "a bit more on xgl":
http://aseigo.blogspot.com/
[^] # Re: radeon et composite
Posté par melalcoolique . Évalué à 1.
Il est tout à fait possible d'utiliser EXA et d'avoir l'accélération matérielle (direct rendering) dans le même temps.
Sous Ubuntu Dapper Drake, il suffit d'installer le paquet libgl1-mesa-dri
cat /var/log/Xorg.0.log | grep exa
cat /var/log/Xorg.0.log | grep render
glxinfo | grep direct
[^] # Re: radeon et composite
Posté par melalcoolique . Évalué à -1.
Il est tout à fait possible d'utiliser EXA et d'avoir l'accélération matérielle (direct rendering) dans le même temps.
Sous Ubuntu Dapper Drake, il suffit d'installer le paquet libgl1-mesa-dri
Ouf!
cat /var/log/Xorg.0.log | grep exa
cat /var/log/Xorg.0.log | grep render
glxinfo | grep direct
[^] # Re: radeon et composite
Posté par MMM . Évalué à 3.
Si, si, Avec pour une radeon (driver libre), OpenGL fonctionne avec Composite activé...
[^] # Re: radeon et composite
Posté par Pinaraf . Évalué à 2.
Composite n'a pas à être accéléré. Un bureau avec composite activé ne rame pas. Un bureau avec un compmgr va ramer si ce compmgr utilise Render !
C'est Render qui est accéléré par EXA.
[^] # Re: radeon et composite
Posté par MMM . Évalué à 2.
Maintenant la meme chose avec xorg 7.0 (avec Option "AccelMethod" "EXA"), ça marche bien... donc y a bien un truc qui a été acceleré, sans doute grace à la nouvelle architecture EXA !
# Mes regrets par rapport a X
Posté par Anthony Jaguenaud . Évalué à 1.
Ce que moi j'aimerai, c'est que X gère la console complète. Hier (10 ans) on parlait de clavier, souris, écran. Aujourd'hui, j'aimerai avoir aussi le support du son. Car une console aujourd'hui, c'est, pour moi, un clavier, une souris, un écran et des enceintes.
J'ai lu la news, mais je ne sais pas si on parle d'une evolution du protocol X, ou d'une implementation particulière ?
[^] # Re: Mes regrets par rapport a X
Posté par sylware . Évalué à 1.
# Ca y est c'es compilé!!
Posté par Pascal . Évalué à 4.
Et bien, c'est loin d'être facile. Il m'a fallu presque 2 jours avant d'avoir un truc totallement fonctionnel, avec les drivers, DRI, etc....
Surtout qu'ils y'a encore quelque bugs dans les configure/Makefile.
Mais le plus complexe, avis aux amateurs, c'est la compilation avec Mesa. En effet, ca a changé par rapport aux versions précédentes. De plus Mesa n'utilise pas les autotools mais des Makefile maison qui sont prévus pour X11R6....
[^] # Re: Ca y est c'es compilé!!
Posté par _Hitek_ (site web personnel) . Évalué à 2.
# board
Posté par Anonyme . Évalué à 2.
http://www.x.org/board/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.