X11R7.0 sous le sapin de Noël

Posté par (page perso) . Modéré par Pascal Terjan.
Tags :
0
22
déc.
2005
Serveurs d'affichage
Pour fêter Noël, la fondation Xorg nous livre la première version majeure de X11 en plus de dix ans : X11R7.0

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

  • # Cher Père Noël...

    Posté par (page perso) . Évalué à 1.

    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...

    « 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 . Évalué à 4.

      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...

        Posté par (page perso) . Évalué à 10.

        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...

        « 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 (page perso) . Évalué à 7.

          est quelques chose d'UNIX.

          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 (page perso) . Évalué à -3.

          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...

            Posté par (page perso) . Évalué à 1.

            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.

            « 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 . Évalué à 7.

              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...

                Posté par (page perso) . Évalué à 1.

                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 (?)

                « 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 . Évalué à 3.

                  Ç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...

            Posté par . Évalué à 6.

            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...

              Posté par . Évalué à 2.

              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...
        • [^] # Re: Cher Père Noël...

          Posté par . Évalué à 10.

          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.


          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 (page perso) . Évalué à 0.

            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.

            « 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 (page perso) . Évalué à 1.

      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...

      Posté par . Évalué à 4.

      >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...

        Posté par . Évalué à 6.

        La transparence en natif, c'est avec composite, ca existe quoi.

        Chez moi X bouffe dans les 30-40 Mo de ram.
      • [^] # Re: Cher Père Noël...

        Posté par . Évalué à 8.

        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...

          Posté par . Évalué à 9.

          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 )
          • [^] # Re: Cher Père Noël...

            Posté par . Évalué à 4.

            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...

              Posté par . Évalué à 3.

              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 :)
            • [^] # Re: Cher Père Noël...

              Posté par . Évalué à 6.

              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...

                Posté par . Évalué à 5.

                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...

              Posté par . Évalué à 4.

              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...

            Posté par . Évalué à 3.

            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...

            Posté par . Évalué à 3.

            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 )


            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 (page perso) . Évalué à 3.

            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...

              Posté par . Évalué à 2.

              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
      • [^] # Re: Cher Père Noël...

        Posté par . Évalué à 10.

        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...

          Posté par . Évalué à 3.

          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...

          Posté par (page perso) . Évalué à 5.

          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.
          • [^] # Re: Cher Père Noël...

            Posté par (page perso) . Évalué à 4.

            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.

            « 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 (page perso) . Évalué à 3.

            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,
    • [^] # Re: Cher Père Noël...

      Posté par (page perso) . Évalué à 10.

      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...

        Posté par (page perso) . Évalué à 1.

        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)

        « 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 . Évalué à 10.

          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...

            Posté par . Évalué à 2.

            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...

          Posté par . Évalué à 7.

          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...

            Posté par . Évalué à 2.

            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...

        Posté par . Évalué à 8.

        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é.
        • [^] # Re: Cher Père Noël...

          Posté par . Évalué à 3.

          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...

            Posté par (page perso) . Évalué à 3.

            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...

              Posté par . Évalué à 3.

              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...

                Posté par . Évalué à 3.

                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).
                • [^] # Re: Cher Père Noël...

                  Posté par . Évalué à 2.

                  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...

                    Posté par . Évalué à 0.

                    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...

                      Posté par . Évalué à 5.

                      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...

                        Posté par . Évalué à 1.

                        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...

                      Posté par (page perso) . Évalué à 1.

                      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)
                  • [^] # Re: Cher Père Noël...

                    Posté par . Évalué à 2.

                    >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...

                      Posté par . Évalué à 2.

                      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...

              Posté par . Évalué à 1.

              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...

      Posté par (page perso) . Évalué à 10.

      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...

        Posté par (page perso) . Évalué à 10.

        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...

          Posté par . Évalué à 0.

          On pourrait aussi prendre le problème dans l'autre sens :
          Mais alors pourquoi est-ce rapide chez les autres (je pense notamment à Quartz) ?


          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 ?

          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 (page perso) . Évalué à 6.

            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...

              Posté par . Évalué à 1.

              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...

            Posté par (page perso) . Évalué à 1.

            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.
        • [^] # Re: Cher Père Noël...

          Posté par . Évalué à 3.

          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...

            Posté par . Évalué à 5.

            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...

          Posté par (page perso) . É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 (page perso) . Évalué à -3.

          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.


          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 (page perso) . Évalué à 4.

            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...

              Posté par (page perso) . Évalué à 1.

              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.


              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 :)


              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.


              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 (page perso) . Évalué à 4.


                La xlib, elle peut faire tant de round-trips qu'elle veut, ca n'empeche pas de faire du double buffering [...] alors pourquoi on n'en a toujours pas, toolkits / WM foireux ?


                Toolkits qui ne tirent pas profit du backing-store.


                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.


                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.


                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 !


                Ben non, c'est le toolkit qui s'en charge.
        • [^] # Re: Cher Père Noël...

          Posté par . Évalué à 1.

          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...

          Posté par (page perso) . Évalué à 2.

          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?
          • [^] # Re: Cher Père Noël...

            Posté par . Évalué à 4.

            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...

          Posté par . Évalué à 3.

          À 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...

          Posté par (page perso) . Évalué à 2.

          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...
          Deux questions relatives a ca:
          • C'est en partie au window manager de gérer ca, non ? De mémoire, certains proposent deja des prefs pour (WindowMaker par exemple, d'apres mes vagues souvenirs)
          • La mémoire de la carte vidéo rentre en ligne de compte, non? Après tout, 128 Mo, sur les cartes qui commencent à en avoir 2 fois plus, ce n'est pas déraisonnable... il faut juste des préférences pour (et la on revient a mon premier point)
        • [^] # Re: Cher Père Noël...

          Posté par . Évalué à 3.

          intéressant.

          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 (page perso) . Évalué à 7.

      X me prenne moins que les 60 à 120 Mo d'occupation mémoire habituel ?


      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 (page perso) . Évalué à 4.

        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...
        • [^] # Re: Cher Père Noël...

          Posté par (page perso) . Évalué à 2.

          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 ?

          « 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 (page perso) . Évalué à 2.

            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)
    • [^] # Re: Cher Père Noël...

      Posté par . Évalué à -6.

      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...

        Posté par . Évalué à 4.

        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...

          Posté par . Évalué à 0.

          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...

            Posté par (page perso) . Évalué à 8.

            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

              Posté par . Évalué à 1.

              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

                Posté par . Évalué à 6.

                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...

            Posté par . Évalué à 3.

            Avec un serveur X traditionnel, tu peux très bien faire des fenêtres en 3D. Cf ma signature :)
  • # fausse joie ?

    Posté par . Évalué à 2.

    c'est pas "à part les radeon r300 et r400" ?
    "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 . Évalué à 2.

      non c'est bien ça, le pilote expérimental pour les r300 (r300.sourceforge.net, mais je pense que ça va être de plus en plus mort après l'inclusion dans mesa et linux).
      • [^] # Re: fausse joie ?

        Posté par . Évalué à 2.

        moi qui ai un Powerbook avec une Radeon 9700, je suis content, par ce que ça me frustrait beaucoup de pas avoir de 3D.
    • [^] # Re: fausse joie ?

      Posté par . Évalué à 2.

      Effectivement, d'après ce document ça ne devrait pas être inclus, bien que le projet r300.sf.net ait transposé ses sources sur le CVS de Xorg il y a de ça un petit moment maintenant.
      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 . Évalué à 4.

        mais glxgears ne me donne pas de chiffre, l'état expérimental du driver en est probablement la cause
        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 . Évalué à 4.

          tout à fait vrai.

          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 . Évalué à 1.

            tu parles,

            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 (page perso) . Évalué à 2.

              J'avais environ 700 avec et sans sur le 6.8, par contre en 6.9 ca a changé, maintenant j'ai toujours 700 sans mais 1400 avec (moi c'est une 855GM)
            • [^] # Re: fausse joie ?

              Posté par . Évalué à 2.

              radeon 7000 (RV100) en 6.8.2 ->~500 fps (16 bit) maintenant 6.9 dri ->~ 900 fps (24 bit en plus), toutes options stable activée( AGP 4X, hyperZ, pageFlip, fast Write).
              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 . Évalué à 1.

                Pour continuer les perfs : driver libre ATI sur 9200 128Mo avec Athlon XP 2GHz, bus 133 MHz, 15% de CPU pour une vidéo donnée. 50% avec les drivers proprios => ATI ne sait pas coder de drivers et a en plus le culot de ps divulguer ses sources (ils ont honte ?).
                • [^] # Re: fausse joie ?

                  Posté par . Évalué à 2.

                  Perso, je pense plutot que ATI ne se concentre pas (du moins pour l'instant) sur les capacités de décompression vidéo de sa puce (d'où des 50% de cpu avec leurs drivers), mais sur le calcul 3D (d'où les meilleurs perfs dans les jeux avec leur driver prorio qu'avec le driver radeon si je me souviens bien des derniers tests que j'ai lu))

                  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 (page perso) . Évalué à 6.

    Chaque nouvelle version d'un programme apporte son lot de nouvelles fonctionnalités. Mais là je pense qu'on a vraiment le droit à une killer feature :
    Support for more than 12 buttons in the generic mouse driver

    (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 (page perso) . Évalué à 4.

      Là y'en a tout plein :)
      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 (page perso) . Évalué à 8.

        Il en manque plus que deux pour couvrire une gamme : Do - Do# - Ré ...

        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 . Évalué à 1.

      La MX1000 de Logitech à 10 boutons (il me semble que dans xorg la roulette compte comme des boutons, ce qui fait 12)... :)
      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 . Évalué à 0.

        chez moi ca marche
        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 (page perso) . Évalué à 4.

          Pour le /dev/input/eventX, si tu utilises udev, tu peux facilement le forcer sur une valeur "utilisable".

          Tu trouveras une manière de faire sur http://floam.sh.nu/index.xhtml?page=guides&section=mx100(...) par exemple.

          Ma configuration est très légèrement différente :

          KERNEL="event*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/event-mx1000" SYMLINK="input/%k"
          KERNEL="mouse*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/mouse-mx1000" SYMLINK="input/%k"


          Il ne reste plus qu'à spécifier le nom du périphérique dans ton xorg.conf.
  • # ptite faute

    Posté par (page perso) . Évalué à 2.

    s/monolythique/monolithique/
  • # Compilation

    Posté par . Évalué à 2.

    J'avais compilé la 6.8.2 relativement facilement mais la j'ai pas l'impression qu'il prend pas mon host.def en compte.
  • # rotation d'écran ?

    Posté par . Évalué à 1.

    le support de la rotation décran sera-t-il implémenté ? (utile pour les pc tablette).

    je parle de la rotation via xrandr.
    • [^] # Re: rotation d'écran ?

      Posté par (page perso) . Évalué à 4.

      Bin ça marche déjà. Ca dépend uniquement de ton driver et de la configuration que tu as mise dans ton fichier xorg.conf.

      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 . Évalué à 1.

        bon ben c cuicui....

        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 . Évalué à 1.

    Aujourd'hui on peut voir que la plupart des toolkits graphiques (ex GTK+, Qt) sont re-écrits pour utiliser des bibliothèques intermédiaires (souvent vectorielles comme Cairo). Par exemple GTK+ est re-écrit sur Cairo. Or cairo, permet de faire un rendu via Glitz, bibliothèque accélérée par des drivers opengl. Glitz a besoin d'un serveur X11 car elle passe par GLX (me semble-t-il). Bientôt, on pourra faire du rendu basé sur opengl egl qui permet de se passer d'un serveur X11. Donc la contrepartie de laisser tomber la flexibilité d'un serveur X11 pour ces nouvelles back-ends sera un gain de vitesse (surement discutable en terme de perception humaine) et un allègement de la lourdeur de l'infrastructure de X11 (discutable aussi, suite à sa modularisation).
    • [^] # Re: Cairo and co...

      Posté par (page perso) . Évalué à 1.

      Ca veut dire que dans quatre matins je ne pourrais plus faire de déport d'affichage graphique depuis mon serveur (sous Linux) vers mon poste client (sous linux) ?
      • [^] # Re: Cairo and co...

        Posté par (page perso) . Évalué à 6.

        Pourquoi pas ? À cause de l'OpenGL ?


        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 . Évalué à 3.

          le driver nvidia est un driver pre DRI (utah glx) .... et l'accélération se fait sur le poste client (le ssh -X ne fait que renvoyer les "requetes d'affichage" des applications du X du server vers le X du client).
          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 . Évalué à 1.

            Je suis intéressé par le driver libre dont tu parles. Si ce dernier expose significativement les APIs des puces de NVIDIA, cela pourrait particulièrement aider les mainteneurs du driver NV de xorg.
  • # radeon et composite

    Posté par . Évalué à 3.

    La nouvelle architecture EXA fonctionne tres bien avec le pilote radeon (pour une 9200). On a enfin un support rapide de l'extention composite.
    • [^] # Re: radeon et composite

      Posté par . Évalué à 2.

      hum interessant ca....
      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 . Évalué à 3.

        De plus utiliser une radeon 9200 permet d'utiliser un driver libre... et c'est un atout de taille !
      • [^] # Re: radeon et composite

        Posté par . Évalué à 2.

        Je ne pense pas que Nvidia intègre le support d'EXA dans leurs pilotes nvidia. Ils ont leur propre système équivalent. Et comme EXA n'est utilisé qu'entre le serveur et le pilote, il n'y a pas besoin d'une compatibilité à ce niveau là.

        Par contre, peut être l'intégreront-ils au pilote nv...
      • [^] # Re: radeon et composite

        Posté par . Évalué à 2.

        Pour nvidia le problème est plus complexe.
        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 . Évalué à 1.

          ah je suis preneur c'est quoi l'option car chez moi pas d'opengl en meme temps que composite
          • [^] # Re: radeon et composite

            Posté par . Évalué à 1.

            Il me semble :

            Option "AllowGLXWithComposite" "Enable"

            Sur une NVidia.
          • [^] # Re: radeon et composite

            Posté par . Évalué à 3.

            Option "AllowGLXWithComposite" "true"

            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 (page perso) . Évalué à 2.

              Tres important : il est impossible d'utiliser OpenGL avec composite active sur une nvidia.
              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 . Évalué à 2.

                t'utilise le pilote nvidia ou nv?
                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 . Évalué à 1.

              Tres important : il est impossible d'utiliser OpenGL avec composite active sur une nvidia.
              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 . Évalué à 2.

                meme question que precedemment, t'utilises quel pilote?

                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 . Évalué à 2.

              Le post concernant l'utilisation d'EXA avec une Nvidia ou une ATI sur le forum anglophone dédié à Ubuntu.

              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 . Évalué à 1.

                Rectificatif:

                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
                (II) LoadModule: "exa"


                cat /var/log/Xorg.0.log | grep render
                (II) RADEON(0): Direct rendering enabled


                glxinfo | grep direct
                direct rendering: Yes
              • [^] # Re: radeon et composite

                Posté par . Évalué à -1.

                Rectificatif:

                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
                (II) LoadModule: "exa"


                cat /var/log/Xorg.0.log | grep render
                (II) RADEON(0): Direct rendering enabled


                glxinfo | grep direct
                direct rendering: Yes
        • [^] # Re: radeon et composite

          Posté par . Évalué à 3.

          >> 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 !

          Si, si, Avec pour une radeon (driver libre), OpenGL fonctionne avec Composite activé...
    • [^] # Re: radeon et composite

      Posté par . Évalué à 2.

      Faux.
      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 . Évalué à 2.

        Enfin bon, en tout cas c'est moi xorg 6.8 + les extentions composite, damage et render + xcompmgr avec une ati 9200 (pilote radeon) = ça rame.

        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 . Évalué à 1.

    Bien, je suis d'accord avec certain, pour la gestion de la transparence.

    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 ?
  • # Ca y est c'es compilé!!

    Posté par . Évalué à 4.

    Je viens de relever le défi.... J'ai compilé et packagé Xorg 7.0.
    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....
  • # board

    Posté par . Évalué à 2.

    Puisque www.x.org tourne avec daCode, rendez-vous sur :
    http://www.x.org/board/

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.