XFree86 est-il assez rapide ?

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
28
oct.
2002
Serveurs d’affichage
Voici deux semaines est paru dans OSNews un article sur la vitesse de XFree86. Cet article a été écrit par Guillaume Maillard du projet B.E.OS, et présente assez bien l'architecture de XFree86 et ses lacunes. Avec l'accord de OSNews j'ai réalisé une traduction disponible en ligne. Si XFree vous intéresse et que vous vous êtes toujours demandé pourquoi le déplacement et le redimensionnement des fenêtres étaient si lent, vous serez sûrement intéressé par cet article.

Aller plus loin

  • # Nouvel icone...

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Bon bah si quelqu'un a un icone sympa à nous proposer pour la section XFree, il est bienvenue ;)

  • # Re: XFree86 est-il assez rapide ?

    Posté par  . Évalué à 1.

    <mode>De toutes façons, XFree, ça suXe</mode>

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  . Évalué à 1.

      Déjà ?
      Mais que va-t-il rester à glandium ?

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  . Évalué à 1.

        le xinerama ;)

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  . Évalué à 1.

        Tiens, templeet m'a mangé mon emulation=glandium dans le tag mode. Encore un bug templeet? FABIEN< !!

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  . Évalué à 1.

          Templeet enlève les attributs de tous les tags, valides ou non, pour éviter que des petis malins rajoutent des attributs style par exemple sur un tag < b >

          Le faire pour les tags valides c'est bien (TM).
          Pour les autres, ca suxe un peu vu que l'utilisation du "parler xml" pour indiquer un contexte particulier est monnaie courante ici.

          Sinon, tu peux utiliser des espaces insécables à la place.

          • [^] # Re: XFree86 est-il assez rapide ?

            Posté par  . Évalué à 1.

            J'avoue ne pas comprendre.

            A priori, vous ne laissez tels quelles que les bornes de la liste ci-dessous. Pourquoi ne pas se contenter de virer les attributs uniquement quand la borne est valide ?

          • [^] # Re: XFree86 est-il assez rapide ?

            Posté par  . Évalué à 1.

            Heu, trop con. Flagrant délit... Oui j'ai lu le second paragraphe après avoir répondu. Ca fait sérieux...

  • # En parlant de XFree

    Posté par  . Évalué à 1.

    J'ai pas envie de faire une news la dessus, mais les develo de XFree cygwin on sorti une version beta du rootless mode (pseudo rootless mode). A voir sur les archives d'octobre de la ML de xfree sur http://www.cygwin.com(...)

  • # Re: XFree86 est-il assez rapide ?

    Posté par  (site web personnel) . Évalué à 1.

    Faire une nouvelle api qui permètre de mieux controler les choses (séparation mémoire client/mémoire serveur/mémoire video), c'est bien, mais je pense que perdre la liaison réseau serait une grave erreur.

    C'est tellement pratique de lancer des applis sur des machines distante et de les controler en locals. C'est vraiment un plus.

    C'est vrai aussi que je me demande depuis longtemps pourquoi X n'utilise pas plus les accélérations des cartes video (il y a nettement plus de choses à faire dans un jeux que dans un wm!).

    "La première sécurité est la liberté"

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  . Évalué à 1.

      Pour quoi perdre la liaison ? N'est-il pas possible de combiner les deux ? Utiliser la nouvelle API pour le local et l'ancienne pour le réseau ?

      Pour la 2D il reste du travail à faire pour les WM et pour les jeux. Je trouve dommage que le simple fait de bouger et de redimenssionner des fenetres surcharge tant le serveur X. Ca clignote de partout, les fenetres mettent du temps à se raffrachir, le déplacement des fenetres est saccadé. Cela ne donne par un air très professionnel du bureau sous Linux.

      Je pense qu'il ya un réél effort à faire sur l'optimisation du serveur X et du gestionnaire de fenetre dans un environnement local. A moins qu'il soit remplacer un jour par un autre projet comme DirectFB.

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  (site web personnel) . Évalué à 1.

        il faut que l'api soit la même ! Sinon, seul celle direct sera utilisé.

        Mais il doit être tout à fait possible, d'optimiser le système, notament éviter que GTK/QT redessine toute la fénètre à chaque fois.

        "La première sécurité est la liberté"

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  (site web personnel) . Évalué à 1.

          Mais il doit être tout à fait possible, d'optimiser le système, notament éviter que GTK/QT redessine toute la fénètre à chaque fois.

          Malheureusement les concepteurs de X ont fait confiance à ceux qui écrivent les applis en se disant qu'ils n'allaient pas trop pousser sur le temps de rafraîchissment de la fenêtre. Ce n'est pas ce qui s'est passé.

          En plus, la fenêtre ne peut recevoir qu'une demande pour tout redessiner. Donc si il y a un seul pixel à redessiner et même si le window manager peut s'en rendre compte il est obligé de demander à l'appli de redessiner tout. Peut-être qu'une extension pourrait faire ça ?

          Sinon, ne touchez pas à notre X qui marche sur le résau, hein parce que moi j'en ai besoin tout le temps !

          • [^] # Re: XFree86 est-il assez rapide ?

            Posté par  . Évalué à 1.

            > même si le window manager peut s'en rendre compte il est obligé de demander à l'appli de redessiner tout

            çà ne concerne pas le window manager.

            > En plus, la fenêtre ne peut recevoir qu'une demande pour tout redessiner.

            Je ne suis pas un spécialiste de X11 mais lors de la demande de "redessinage" de la fenêtre X11 (l"appli a généralement une arborescence de fenêtre X11) l'appli reçoi aussi les coordonnées à redessiner dans la fenêtre X11 à redessiner (un tableau de rectangle).
            Enfin certains serveurs X11 conservent l'image des fenêtres et c'est le serveur qui redessine la fenêtre (ou une partie) sans que l'appli ne soit dérangée. Mais je crois que pour tirer parti de cette fonctionnalité, l'appli doit faire une demande explicite au serveur et çà bouffe de la mémoire.

            Mais je dis peut-être des conneries...

            • [^] # Re: XFree86 est-il assez rapide ?

              Posté par  (site web personnel) . Évalué à 1.

              Là, ça m'interesse. Dans un wm que j'écris je reçois que des "expose" et du coup je redessine brutalement tout le cadre (je parle ici de wm car je pense que c'est vrai pour toute appli X, y compris les wm). Et je trouve ça très nul. Par exemple, quand j'ai mis une fonte freetype j'ai été obligé de la cacher dans un pixmap pour pas que ça lague de partout.

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  . Évalué à 1.

                Je n'ai pas le temps de retourver l'info. Et je n'ai plus le livre où j'ai lu çà.
                C'est oreilly "Volume 1: Xlib Programming Manual" .
                http://www.oreilly.com/catalog/v1/(...)

                > > Enfin certains serveurs X11 conservent l'image des fenêtres et c'est le serveur qui redessine la fenêtre

                Le programme ee semble utilisé çà.
                $ ee toto.png &
                [1] 28310
                $ kill -SIGSTOP %1

                bouge, rédimention la fenêtre, etc... l'image est toujour là.

                Fait la même chose avec une autre appli. Si la fenêtre est déplacée, X11 affiche ce qu'il connait (ce qui n'est pas masqué par une autre fenêtre). Sous-entendu qu'il attend de l'appli l'affichage du reste mais pas de tout le contenu.

          • [^] # Re: XFree86 est-il assez rapide ?

            Posté par  (site web personnel) . Évalué à 1.

            En plus, la fenêtre ne peut recevoir qu'une demande pour tout redessiner.

            Tu es vraiment sur ? :-)

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  (site web personnel) . Évalué à 1.

      je pense que perdre la liaison réseau serait une grave erreur

      J'utilise aussi la liaison réseau dans certains cas, mais il faut reconnaitre que c'est plutôt exceptionnel.
      Voici ce que je voudrais : un bureau réellement accéléré, sans support réseau, mais avec la possibilité de lancer, quand j'en ai besoin, un "xfree réseau" en fenêtre, quitte à ce que celui-ci soit plus lent.

      Ceux qui utilisent souvent le réseau ayant toujours la possibilité d'installer un xfree tel qu'on le connait actuellement, bien évidemment.

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      C'est tellement pratique de lancer des applis sur des machines distante et de les controler en locals. C'est vraiment un plus.

      Un plus ? On sacrifie des optimisations de l'affichage pour quelques guru qui s'amusent à controler leurs machines sous X. Ces même guru qui s'empressent d'ouvrir des Xterm pour utiliser leurs applications préférées en mode console ...

      J'ai honte. OUI, j'ai honte de montrer que l'économiseur d'écran Matrix bloc de temps à autre. Le contrôle à distance, c'est bien marrant, mais c'est inutile pour la majorité des utilisateurs. Bref, il faudrait qu'une option de compilation permette d'avoir un serveur X exportable sur le réseau, et un serveur X local, et strictement local.

      C'est pour ces quelques raisons que je pense que la connection réseau du serveur X est un moins, dans une utilisation générale.

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  (site web personnel) . Évalué à 1.

        Et isl font comment les etudiants pour se logguer sur le serveur depuis les TX ?
        c'est bien pratique
        d'autant plus que la partie réseau tu l'utilises aussi autrement en lancant des appli X via ssh .
        Bien pratique de lancer kmail a la maison depuis le boulot pour lire le courrier... ou tout programme graphique, moi je veux garder cette architecture client serveur, mais il est clair qu'en local y a moyen d'accelerer les choses.

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  . Évalué à 1.

          Bien pratique de lancer kmail a la maison depuis le boulot pour lire le courrier... ou tout programme graphique, moi je veux garder cette architecture client serveur, mais il est clair qu'en local y a moyen d'accelerer les choses.

          Ben y en a qu'ont pas froid aux yeux... tu ferais mieux d'installer un serveur IMAPS...

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  (site web personnel) . Évalué à 1.

        L'affichage déporté de X ne sert pas qu'à quelques Gourous un peu partis. Que ce soit à la fac, en entrprise ou même à la maison, beaucoup de personnes l'utilise et c'est une des grandes forces de X. Il est si pratique qu'il suffit d'aller faire un tour sur certains newsgroup pour se rendre compte que plein de gens cherchent la même chose sous Windows.

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  . Évalué à 1.

        On sacrifie des optimisations de l'affichage pour quelques guru qui s'amusent à controler leurs machines sous X.

        Ou des tas d'écoles, collectivités, assoces, qui n'ont pas le fric nécessaire pour acheter des stations tip-top, et préfèrent donc centraliser les calculs sur un gros serveur X auquel ils connectent des 486/Pentium de récup recyclés en terminaux X.

        Penser à Abuledu, aux pays sous-développés...

      • [^] # Maastrix

        Posté par  . Évalué à 1.

        Au fait, moi, ce dont j'aurais honte, c'est de montrer que j'utilise un économiseur d'écran Matrix ;-))

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  (site web personnel) . Évalué à 1.

        J'ai honte. OUI, j'ai honte de montrer que l'économiseur d'écran Matrix bloc de temps à autre.

        Ce dont j'aurais vraiment honte, ce serait d'abandonner les 10 ans d'avance qu'a X sur les autres systèmes d'affichage au nom de la sacro-sainte performance.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  (site web personnel) . Évalué à 1.

        J'ai honte. OUI, j'ai honte de montrer que l'économiseur d'écran Matrix bloc de temps à autre.

        Oui, c'est un scandale, tu as raison ! Supprimons une feature extrèmement utile à des milliers d'utilisateurs, que même Windows a fini par rajouter, juste pour qu'enfin, ô joie, tu n'ais plus honte car ton zouli screensaver de neuneu ne se bloquera plus.

        Lequel screensaver ne bloque surement pas à cause des capacités réseau de X, et ne sert qu'a continuer de faire chauffer ton CPU et bouffer inutilement du jus à ton moniteur qui ne demande qu'a se mettre en veille.

        (En général je prend le parti des utilisateurs de base contre les soi-disants gourous, mais là tu pousses un peu).

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  . Évalué à 1.

          Lequel screensaver ne bloque surement pas à cause des capacités réseau de X, et ne sert qu'a continuer de faire chauffer ton CPU et bouffer inutilement du jus à ton moniteur qui ne demande qu'a se mettre en veille.

          si il a une carte ATI, qu'il aille se renseigner sur GATOS(.sf.net), il y a des gros bugs dans les implémentations DRI/DRM notament sur l'accès DMA. Ce pourrait bien être ça.
          Sur certaines Matrox aussi je crois qu'il peut y avoir des ennuis du meme genre.
          Sinon si il est en AGP 4X, qu'il essaye de redescendre en 2X, il y a des bugs avec certaines cartes mères, qui sont contournés par les drivers sous Windows, mais bien évidemment pas sous Linux. Un upgrade de BIOS aide parfois à résoudre le problème aussi.

          Dans tous les cas, la solution de base à tenter lorsqu'on a le serveur X qui bloque, c'est de virer le "Load dri" du XF86Config. Si ça résoud le problème, alors faut s'intéresser aux drivers DRI/DRM provenant direct du CVS ou bien à des projets tels que GATOS qui fournissent des drivers bien déplombés.
          Sinon, mettre à jour vers la dernière version de XFree aide parfois aussi, mais en général ce n'est pas suffisant, il faut encore aller piocher ailleurs (dans les projets susnommés), notamment si on a une ATI AIW ou avec TVOUT.

          Bref, en résumé, il y a des milliers de raisons, certaines matérielles, d'autres provenant souvent de la mauvaise intégration de XFree réalisée par certaines distro, qui peuvent expliquer pourquoi le screensaver se fige, et XFree n'est qu'un des coupables possibles...

  • # Re: XFree86 est-il assez rapide ?

    Posté par  . Évalué à 1.

    Juste quelques commentaires sur XFree86 et les perfs:
    XFree86 fait pas mal de concessions sur les perfs au nom de la sacro sainte portabilitée et passe souvent son temps a réinventer la roue. On peut citer par exemple la gestion complète en userspace de tous les devices d'entrés (en train de changer pour Linux en branche HEAD et kernel 2.5 qui utilise l'events API), la réimplémentation complète de toute la gestion PCI (qui quand y a des bugs et interfere mal avec le noyau crashe la machine), réimplémentation de l'I2C, des drivers tuner et de beaucoup de choses dans la Xvidéo extention étant du ressort de V4L(2) sous Linux (attention, je n'ai pas dit que la XVideoEntention n'était pas nécessaire, cetaines choses sont de sont ressort et pas de celui de V4L).
    Du fait de son extrème portabilité et de son mode full userspace, et bien exit les transferts DMA pour les pixmaps, exit la synchro verticale avec les interrupts et j'en passe...
    L'arrivée du DRI commence a bouleverser les choses et certains drivers commences a profiter de cette petite incursion kernel (DRM) pour détourner sa raison originelle (la 3D client side) pour par exemple tranferrer les images YUV (Xvideo) en DMA (ATI), dans le CVS du DRI/DRM on commence a voir apparaitre la gestion du vertical retrace sous interruption pour décharger le CPU et la carte GFX (pourquoi calculer 2000 frame secondes quand votre écran en affiche au mieux ~100 sans parler des effets de fliker). D'ici que le serveur X puisse utiliser cette fonctionnalité, y a q'un pas. (driver ATI et MGA).
    (enfin pas tout a fait, faudrai que le serveur X ait enfin un client DRI intégré ou que les gens de XFree décident de définir un DRM like pour autre chose que la 3D et le DRI).
    Si on essay d'avoir une vision plus globale, un XFree "optimisé" tirerais au mieux parti de l'infrastructure fournie par le kernel:
    - utilisation de l'interface FrameBuffer pour acceder à la carte au lieu de réinventer la gestion PCI, SBUS etc...
    - utilisation de l'API native pour la gestion des claviers/pointeurs.
    - avec un raprochement du DRM et de l'interface FB, l'utilisation systématique des DMA pour les transferts de données supéreurs à une certaine taille.
    - utilisation des interruptions pour la gestion de la synchro verticale.
    - utilisation systématique de V4L pour le partie input de la XVideoExtention.
    - gestion mémoire de la carte plus évoluée et unifié au niveau kernel entre le DRI/DRM, XFree, FB, V4L (très important pour les carte type Matrox Marvel, ou ATI All In Wonder). Les problématiques de gestion de la mémoire de ces cartes, sans être aussi complexe que la VM du noyau, sont de moins en moins triviales. Un premier travail est effectué dans ce sens dans une branche particulière du DRI, visant à ramener a terme la gestion de la mémoire des textures dans le noyau pour la partager entre tous les clients 3D.

    Bref, beaucoup de chemin reste a parcourir, mais le train est en marche même si c'est loin d'être un TGV. Rien en tout cas ne necessite une remise en cause globale de ce qui existe en terme d'architecture haut niveau. Ce n'est qu'un pblm d'implémentation.
    Par contre messieurs les codeurs de toolkits graphiques et d'application, s'il vous plais, validez votre design, profilez vos aplications et vos librairies, en 6 ans d'évolution, c'est devenu une catastrophe sur ma machine alors que les applis sont juste un peut plus jolie et ne font strictement rien de plus... Bien codé, l'ensemble devrais être aussi sinon plus rapide que l'équivalent de l'époque.

    Un dernier mot en ce qui concerne XFree: Un grand merci au personnes de XFree et du DRI et que la force soit avec vous.
    Pour les currieux, estimez a combien se monte le nombre total de personnes directement impliqués dans le dev de XFree et du DRI, vous serez étonnés. Comme quoi les choses tiennes à pas grand choses.
    Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  . Évalué à 1.

      très bon article! vraiment.

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  . Évalué à 1.

      Un truc qui manque aussi à mon sens: Que chaque nouvelle extension ait une implémentation par défaut, débrayable par une implémentation optimisée par le driver spécifique quand celui ci est disponible.
      L'écriture des drivers est de plus en plus complexe et donc prend de plus en plus de temps (il n'y a toujours pas de support correct pour l'ATI Mach64, qui est antidéluvienne, et la Rage128 a du support 16 et 24 mais pas 32bits, et l'accès DMA est catastrophique - peut etre une limitation hardware qui m'a échappé, mais c'est curieux - , quand aux Radeon, elles sont très diversement supportées. Et je cite ATI parce qu'ils fournissent quasi systématiquement leurs specs 2D et 3D). En conséquence, certains matériels restent de manière totalement absurde de coté pour certaines fonctionnalités (typiquement XVideo, XRender), alors qu'une implémentation par défaut le leur donnerait au prix certes de performances médiocres.
      Dans la même lignée, rapprocher DRI/DRM, XFree, FB, etc. ce serait une très bonne chose, car j'ai l'impression que c'est l'une des raisons pour lesquelles les pilotes XFree sont si longs à écrire.

      • [^] # Re: XFree86 est-il assez rapide ?

        Posté par  . Évalué à 1.

        de support correct pour l'ATI Mach64, qui est antidéluvienne,


        La prochaine version di DRI devrai te combler, quelques développeurs (2-3) se sont mis au travail en passant par la difficile phase d'apprentissage de l'architecture et des sources de XFree/DRI et ca a fini par porter ses fruits.

        En conséquence, certains matériels restent de manière totalement absurde de coté pour certaines fonctionnalités (typiquement XVideo, XRender), alors qu'une implémentation par défaut le leur donnerait au prix certes de performances médiocres.


        C'est le cas pour XRender, cela a d'ailleur des effets pervers: beaucoup de cartes n'ont pas nécéssairement le support adéquat révé pour l'implémenter, d'où la difficulté, d'où le fait que l'on reste sur plus de 90% des drivers sur l'implémentation soft par manque de codeurs qualifiés sur XFree.

        La disparité des interfaces et sous systèmes a prendre en compte participe à la difficulté d'écriture des drivers XFree. Prenez par exemple le problème de switch vers une VC Linux: pas de support noyau, pas de moyen de com entre les deux, pas d'interaction possible entre les deux d'où une aproche empirique de XFree pour sauvegarder et restaurer les bons registres avant et après le switch.
        Avantage: system independant.
        Inconvénient: un truc bouge dans la gestion console du noyaux; ca casse. Un truc bouge dans le code accéléré de XFree sans prendre garde à cet obscur cas particulier; ca explose. Le drivers n'en est pas pour autant de mauvaise qualité.

        Les cartes graphiques actuelles deviennent des monstres de complexités. A coté, la complexité de nos UC et CPU fait presque palle figure. La tandance vers laquelle je crois il faudrais se tourner c'est de considerer nos cartes comme de vrai machines leur drivers devenant aujoud'hui de propres OS.
        Alors, un support OS host devient une évidence (merge fb/drm/...) et une base commune de code peut émerger, simplifiant l'écriture de driver.

        Un driver carte ethernet Linux est facile a écrire aujourd'hui, même avec une plétore d'accélérations (zerocopy/checksum, bientot crypto ...) même un portage du système complet sur un nouveau CPU/Architecture se fait de plus en plus facilement. Pourquoi ?
        - Base système commune (c'est le plus important)
        - 10 ans d'expérience et de maturation pour construire cette infrastructure système (Kernel arch independent).
        - Beaucoup de développeurs et un bon arbitre.

        L'architecture de XFree a fait un bout du chemin (le DDX pour la 2D) mais necessite aujourd'hui une infrastrucure noyaux qui se cherche pour tirer parti de nos rolls du pixel.

        Pour répondre à la problématique "partie réseau qui me sert peu et ralentit tout":
        C'est faux: X11 utilise en local les socket Unix et pas TCP/IP. De plus une étude a été mené par Keith Packard il y a quelques années déjà pour savoir si un mode mémoire partagé pour la transmission des messages entre le client et le serveur ne serait pas plus avantageux. Le résulat est éloquent: le mode message est bien plus léger et plus rapide, la gestion des ordres X11 en mode block au travers d'un segment de mémoire partagé faisant écrouler les perfs.
        Par contre, pour la manipulation des Bitmaps, l'extention XShm est bien entendu indispenssable.
        Néanmois, pour parler de celle ci, même en l'utilisant, de part la très faible interaction entre le noyaux et le serveur, plusieurs copies mémoire sont réalisés avant que vous obteniez votre image à l'écran. Ici pas de zérocopy! (dito pour XVideo). Quand on sait ce que coute une copie mémoire sur du graphique ....

        Comment définitivement régler le pblm et obtenir les perfs des interfaces graphiques client side (directfb/gtkfb) tout en gardant l'ensemble des fonctionnalités X11 ? (séparation conceptuelle client / serveur d'ailleur respectée même avec le DRI pour OpenGL/GLX) ?
        - remonter la gestion de la mémoire graphique/texture/video... au niveau d'un nouveau gestionnaire kernel (la VM graphique en quelque sorte).
        - réviser la XShm pour éliminer les incohérences rendant difficile l'implémentation d'un fonctionnement ZeroCopy. (histoire de travailler non plus avec des segment de mémoire partagé IPC Unix, mais avec un segment partagé entre la VM graphique, le serveur X et le client X si celui ci est local. Du coup, l'extention deviendrait presque transparente vu du programmeur).

        On obtiendrais alors les avantages du client side sans avoir plus tard a inventer des truc a la metaframe and co pour palier au pblm.

        Boouuuhhh, faut que je me calme, j'ai pas l'habitude d'écrire de tels romans!! ;-)

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  (site web personnel) . Évalué à 1.

          +

          Hein, quoi, plus de + ?

          Pourquoi y'a plus les + ?

          Ouin.

          Oui, je sais, -

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  (site web personnel) . Évalué à 1.

          [+]

          Ce que tu racontes est quand même très optimiste !

          Il faudra encore attendre que cela bouge. C'est vrai que je suis surpris qu'aucune carte "moderne" ne soit supporter par DRI (sauf la dernière de Matrox, lente et chère). Pour ati, ils sont à la 7500, le drivers 8500 vient juste de sortir mais en étant un peu limité. Je ne parles pas de nvidia qui fait joujou dans son coin.
          Et les ati 9x00, n'ont toujours pas l'air supporté.

          nicO

          "La première sécurité est la liberté"

          • [^] # Re: XFree86 est-il assez rapide ?

            Posté par  . Évalué à 1.

            C'est a la fois optimiste est pessimiste:

            Optimiste parce qu'il y a des solutions et que l'on se dirige lentement vers elles.

            Pessimiste à cause de cette lenteur et également du fait que les quelques développeurs XFree, a tord ou a raison sont très conservatifs. Dans leur contexte, je les comprend, les chiffres sont là:
            Développement du driver 2D ATI: ATI + revu et corrigé par deux ou trois personne de XFree (chapeau ATI).
            Développement du driver 3D ATI Rage, 7500, 8500, 9x00: a peut de choses près 1 personne (Keith Whitwell) et encore il est payé pour et seulement pour un modèle precis de la dernière génération. (et il en sort un paquet par ans de carte. lire: dès qu'une nouvelle carte sort, on oubli les vielles même si le driver n'est pas fini).
            Développement du driver 3D Mach64: 2 personnes qui sont reparti de rien, le driver n'ayant pas de sponsor commercial, Keith a arrêté de travailler dessus (c'était sur son temps perdu).
            Developpement driver Matrox: Après une participation de Matrox pour le driver 2D et 3D, plus rien. Le driver est en mode pseudo maintenance alors qu'un bon dépoussiérage vous blufferai sur ce que l'on peut encore tirer de ces cartes.
            Travail sur OpenGL: Brian Paul. Pourtant c'est un sacré monstre.
            Travail évoqué précédement sur le gestionaire de texture unifié: 1 personne Ian Romanick qui travaille pour IBM.

            Je passe sur le problème nvidia et de leur driver fermé / politique vis a vis des specs et ce ne sont pas les seuls...

            Conclusion:
            Pour avoir
            - plein de drivers
            - de bons drivers
            - des drivers performant donc s'appuyant sur une bonne infrastructure.
            Il faut plus de développeurs.

            Comment ?
            Ben c'est là que j'ai pas la solution. Faut arriver a impliquer/interresser plus de monde, plus de boites, plus de sponsors.
            Tout le monde utilise XFree (même sous Windows, j'en connais plein...), il a le mérite d'exister tel qu'il est. D'un autre coté, et c'est là ou est le paradoxe, tout le monde râle, mais tout le monde s'en contente.

            Comparez le nombre de lignes de codes de XFree / DRI / DRM / Mesa et de sa poigné de développeurs avec
            le nbre de lignes de code source de Linux et son bon millier de développeurs majeurs.
            Pourtant la complexité des deux projets est similaire. Je vois mal aujourd'hui Linus faire avancer Linux avec moins d'une vingtaine de développeurs majeurs. Même s'il a les meilleures idées du monde en ce qui concerne "comment faut faire" au niveau de l'architecture logicielle et vers quoi il faut aller.

            Alors si qqu'un a le remède miracle quand à la désertion des développeurs qu'il agisse et vite sinon on est pas près de sortir de ce paradoxe.
            Bienvenu dans la quatrième dimension !

            • [^] # Re: XFree86 est-il assez rapide ?

              Posté par  . Évalué à 1.

              Oui mais pour pouvoir aider, il faut à mon avis de sacrées compétences techniques. Les compétences comme celles-là, ca se payent.

              Au vu des tonnes de projets inachevés (ou jamais commencés) sur sourceforge, j'en conclus qu'il y a beaucoup d'intention ponctuelle mais pas de suivi à long terme.

              <mode>Est-ce que on aurait atteint les limites du développement du LL ? (Si tout le monde ne passait pas son temps à développer un énieme "Window player like", peut-être que l'on pourrait progresser)</mode semi-troll>

            • [^] # Re: XFree86 est-il assez rapide ?

              Posté par  . Évalué à 1.

              Ben.. perso j'ai essayé de m'intéresser au problème. A mon avis, un des problèmes majeurs de XFree c'est l'énorme difficulté de "pénétration" du projet.
              Pour le Kernel, il est à la fois plus modulaire et plus documenté.
              Pour XFree, il faut pratiquement s'intéresser à la totalité pour arriver à bouger un truc dans un coin, et surtout rien n'est correctement documenté. On manque totalement de points d'entrée dans le projet... Chaque extension est (partiellement) documentée indépendament des autres.
              Quand aux docs des drivers, ça se limite vraiment au strict nécessaire, et ça frise parfois de la publicité mensongère:
              http://www.xfree.org/4.2.1/r1282.html#2(...)
              "including hardware accelerated 2D drawing" heu oui, sauf que toutes les extensions 2D ne sont pas complètement accélérées (aux dernières nouvelles, le DMA ne marchait toujours pas pour XVideo, le développeur ayant abandonné le dev en cours de route). Quand au reste de la doc de ce driver elle est.. comment dire... le moindre des modules du noyau linux est mieux documenté que ça, largement mieux (voir nottament http://www.xfree.org/4.2.1/r1283.html#3(...)). Et tout l'ennui c'est que la réponse habituelle (t'as qu'à faire mieux toi meme), ne marche pas, car c'est vraiment très compliqué, ça prend beaucoup de temps de rentrer dedans.

              Quand à la Mach64, le machin avait l'air tellement velu que le sieur LT (un finlandais), est venu leur donner un coup de main (notamment sur l'utilisation du DMA, de ce qu'ils avaient droit de faire coté DRM ou pas, comment le faire, etc.). Et pourtant, la Mach64, c'est loin d'être la carte graphique la plus complexe (vu son age entre autres). Ceci dit, je crois pas que ce sera présent dans XFree 4.3.0, aux dernières nouvelles ils n'avaient pas encore tout à fait fini, donc ptet ben qu'oui ptet ben qu'non (mais mes nouvelles datent du début du mois).

              Pour finir pour Render, ça a fini par etre le cas, mais il me semble que dans XFree 4.0.x il n'y avait pas d'implémentation par défaut, c'est venu en 4.1.0. Mais là encore je me trompe peut etre.

              Pour le reste, je suis d'accord avec toi, mais là on a un problème d'oeuf et de poule: y'aura pas plus de programmeurs tant que ce sera pas mieux documenté, et y'a pas assez de programmeurs pour mieux documenter...
              J'espère qu'une distro va en avoir assez pour affecter des gens sur la chose, ce sont les seuls qui peuvent nous sortir du cercle vicieux, mais ça va leur couter cher, et le démarrage risque d'etre long.

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  (site web personnel) . Évalué à 1.

                Et pourtant, la Mach64, c'est loin d'être la carte graphique la plus complexe (vu son age entre autres)
                Pour les jeunes : sachez que mon Pentium 90 de septembre 1996 a ce chipset.

                Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  . Évalué à 1.

                Techniquement j'y comprend presque rien à X11 (même si j'ai déjà développé avec Xlib,Xt,Xm).
                Mais un truc est sûre. Lorsque l'on va sur http://www.xfree.org/(...) ben on n'est pas pris d'une envie subite d'aider le projet.

                Il faudrait beaucoup plus de visibilité du projet sur le site web !

                • [^] # Re: XFree86 est-il assez rapide ?

                  Posté par  . Évalué à 1.

                  tu sais quand on va sur kernel.org c pas hyper top mieux non plus, mais l'arbo "Documentation" du noyau, ça, c'est quelque chose ! et chaque gros ensemble du kernel est lui même très bien documenté, la plupart étant gérés comme des projets indépendants avec leurs propres pages, ML, documentation, etc.
                  Pour XFree, seul le DRI bénéficie de ce traitement....

            • [^] # Re: XFree86 est-il assez rapide ?

              Posté par  . Évalué à 1.

              Je crois que tu soulève bien le problème de la participation.

              <mavie>
              J'ai entre 0 à 10 heures de temps consacré au "soft" par semaine. Je passe le plus claire de mon temps à lire du code source pour comprendre comment fonctionne telle ou telle programme. Bref, je fait de la culture générale de "codeur".

              Un jour, sur un coup de tête, je me suis acheté une Matrox G450 pour remplacer ma NVidia. Je me suis dit pourquoi ne pas essayé de voir comment fonctionne la Matrox et essayer de m'amuser avec en la programmant directement (et la faire tourner sur L4 mais ça c'est une autre histoire).
              Récupération (partielle) des specifications. Aïe ! c'est vraiment pas évident. Pourtant le hardware je suis en général à l'aise (comme tu le dis .. un Chipset ou un CPU, c'est super simple à coté !). Je compte sur XFree pour m'aider un peu et ... je suis de suite effrayé par la monstruosité du "bidule" ! La doc est quasi inexistante par rapport à la taille du projet ... et le code peu (voir non) documenté.
              </mavie>

              Bref, XFree manque de développeur, c'est pas nouveau. Mais n'est-ce pas finalement un choix volontaire de quelques programmeurs plutôt que le manque de volonté de programmeurs extérieurs au projet.
              Avec le recul, j'ai l'impression que XFree est (était?) le "privilège" de quelques programmeurs et qu'ils n'ont jamais voulu laisser leur "bébé" dans des mains étrangères. En limitant la documentation au minimum je pense qu'ils se sont assurés que personne d'autres ne prendrait contrôle du projet XFree. Je ne penses pas que cela soit un comportement généralisé mais le fait de quelques programmeurs seulement. Il est même possible que le fait soit ancien et que la taille actuelle du projet ne permette plus de le documenter en un temps résonnable.

              ps: merci pour tes commentaires. ça fait du bien d'en voir d'aussi beau !

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  (site web personnel) . Évalué à 1.

          Beaux commentaires, ça nous change des commentaires crétins habituels pour nous dire que xfree sux.

        • [^] # Re: XFree86 est-il assez rapide ?

          Posté par  (site web personnel) . Évalué à 1.

          Moi je crois plutôt à une alternative : de nos jours, les toolkits utilisés sont de plus en plus découplés de X11 ... avoir le choix d'utiliser soit X11 soit DirectFB par exemple ne serait pas un boulot énorme à réaliser (Gtk tourne sous DirectFB, GNUstep c'est en cours, et Qt tourne en FrameBuffer, le portage ne devrait pas être si complexe).

          Cela permettrait d'utiliser le meilleur backend (X11, DirectFB, SDL ?) suivant l'utilisation du moment qui nous intéresse. D'autant qu'il existe un serveur XFree pour DirectFB, pour d'éventuelles applis à distance (voir http://www.roard.com/screenshots/screenshot_directfb.png(...))

          Franchement je pense que pousser DirectFB pour une utilisation desktop est plus intéressant que bidouiller X11 pour arriver à des performances potables :-/
          (disons, on pourra y arriver, mais je pense qu'on y arrivera plus rapidement à partir de DirectFb...)

          • [^] # Re: XFree86 est-il assez rapide ?

            Posté par  (site web personnel) . Évalué à 1.

            Sven Neumann espere que les gars de xfree vont intégrer xdirectfb mais il n'a aucune idée de ce qu'ils en pensent.

            • [^] # Re: XFree86 est-il assez rapide ?

              Posté par  (site web personnel) . Évalué à 1.

              le paradoxe quand même c'est que je démarre xdirectfb quasi-instantanèment, alors que XFree mets 2-3 secondes ...
              Et d'après les benchs sur http://www.directfb.org(...) xdirectfb serait même plus rapide au dessin !
              Non franchement, le truc qui manque à directfb se sont des drivers ... :-/

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  . Évalué à 1.

                >Non franchement, le truc qui manque à directfb se sont des drivers ... :-/

                Eh bé oui ... et on en revient au problème de X, avec les pikotes en retard ou proprio.

                • [^] # Re: XFree86 est-il assez rapide ?

                  Posté par  (site web personnel) . Évalué à 1.

                  oui... avec peut être (?) la différence que les pilotes DirectFB ont l'air plus simples à écrire malgrès tout. Mais bon...

                  • [^] # Re: XFree86 est-il assez rapide ?

                    Posté par  . Évalué à 1.

                    Et avec un peu de chance, les pilotes sont mieux documentés et l'api plus simple à comprendre. Conclusion, DirecFB pourrait bien rattraper xfree ...

                  • [^] # Re: XFree86 est-il assez rapide ?

                    Posté par  . Évalué à 1.

                    Mais offrent-t-il le meme niveau de fonctionnalité?
                    Accélération 2D, 3D, etc..

                    En général quand c'est beaucoup plus simple c'est qu'il manque des feature.. Ou alors c'est que l'historique de X/XFree a compliqué les choses.

                    Note que je n'affirme rien ni dans un sens ni dans l'autre, je pose juste la question.

            • [^] # Re: XFree86 est-il assez rapide ?

              Posté par  . Évalué à 1.

              Ok, directfb est interressant, mais répond à 5% de la problématique en réinventant la roue.
              Pourquoi xdirectfb ?
              Parceque directfb n'est qu'une interface framebuffer noyaux (on a déjà) avec quelques primitives accélérées kernel (les drivers xfree natifs vont beaucoup plus loin). Maintenant dans le framebuffer on veut gérer des fenêtres et une cohabitation entre plusieurs applis. Donc ? et bien on a rien trouvé de mieux que de faire un serveur X s'appuyant sur directfb... Et si je veut utiliser de la 3D cablé avec directfb, je fait comment ? je réinvente un DRI en user space dans la lib directfb et je code un nouveau DRM dans mes drivers kernel directfb ?

              On tourne en rond !!!

              Certe, pour du mono appli genre embarqué, directfb est un killer. Mais au lieu de se disperser, imaginez que ces mêmes personnes aient réalisés le merge entre le drm et le linuxfb plustot que de travailler dans leur coin. On obtiend un super linuxfb utilisable en direct rendering exactement comme directfb (profitant des irq pour la synchro verticale, les dma, ...) avec un xfree nouvelle génération tel qu'évoqué précédement pouvant s'appuyer dessus.
              Au lieu de réunifier les sous systèmes créés à l'origine pour répondre à une problématique précise, on disperse tous nos efforts dans dix mille directions à la fois...

              X11 est un système super léger, si si je vous jure, il tounais déjà quasi a l'identique sur les machines des années 80 avec qques méga de ram.
              XFree (pas X11) souffre aujourd'hui de quelques défaults/limitations d'implémentation.
              (pour les défault de X11, c'est une autre histoire et je vous invite a suive les dev sur la liste XFree et dans le CVS et lire les papiers de Keith Packard pour voir les evolutions apportés aux pblm de design de X: XRender, XRand, ShadowFB, fontconfig, XCursors ou un truc du genre, etc...).
              Plustot que de foutre à la benne 20 ans d'expérience il suffirait de corriger ces quelques défault d'implémentation pour que tout le monde soit content sans même que vous vous rendiez compte des défault de conception/age de X11 évoqués entre parenthèses au paragraphe précédent.

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  (site web personnel) . Évalué à 1.

                Mais non mais non. On est sur DLFP, et ici il est de bon goût de critiquer X11.
                Si tu ne le fais pas, tu vas te faire lapider par la populace en délire.

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  . Évalué à 1.

                Pour répondre a moi même, je sais bien que "il faut ... il faut", c'est vite dit et que avec des si on mettrait Paris en bouteille.

                Enfin pour répondre à anonyme512, il est plus que vrai que le défault majeur de XFree/DRI explicant le peu d'implication des développeurs est le manque global de doc du code du projet vis à vis de la complexité de celui ci.

                La, pareil, fadrait un petit remède miracle ou une petite incatation vodoo histoire de corriger le tir.

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  . Évalué à 1.

                c'est le grand mal de Linux, je l'ai deja dit, à savoir la centralisation des données et du travail groupé. Trops de projets, aucunes autorités (j'entend par là un chef ou des chefs de groupes) bon c aussi ca le LL, la libèrté mais à quel prix?
                Donc pour X, comme dit Emmanuel ca s'barre dans tous les sens.

                C'est le même cas pour le Noyau Linux. un seul Chef Linus, les avancées sont très lentes, les supports inéspèrés. Bon je sais plus trop ce qu'il en est là (j'ai levé le pied d'puis un bout de temps), mais les sois-disantes nouveautés prévues pour le kernel 2.6 auraient pu être bien plus précoces mais non, il y a eu cette disparité entre les dev, des quinzaines de patch par version venant d'une dizaine de dev singuliers.

                En tout cas je ne savais pas que la situation était aussi bordelique pour Xfree, je suis
                content qu'un article de ce genre est apparu.

                A combien de personnes s'élèvent la XFree team ?

                A+

              • [^] # Re: XFree86 est-il assez rapide ?

                Posté par  (site web personnel) . Évalué à 1.

                Clairement, X11 a du souffrir d'un défaut d'implémentation, car avec son age, on se demande pq aujourd'hui il n'est pas plus rapide.

                D'un autre coté, les exigences en matière de desktop sont présentes maintenant, et il faut se demander si X11 peut arriver à les suivre...

    • [^] # Re: XFree86 est-il assez rapide ?

      Posté par  (site web personnel) . Évalué à 1.

      Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))

      Ca me donne une idée : pourquoi linuxfr ne pourrait-il pas aider à fédérer des projets ? Après tout c'est parfaitement dans l'esprit du logiciel libre et il y a plein de développeurs dans le coin.

      Par exemple : news sur XFree, il y en a qui trouvent XFree trop lent, on pourrait alors décider de réimplémenter (je dis n'importe quoi là) les fonctions de copie de pixmap pour qu'elles utilisent des blit en hardware si elles sont exécutées en local. Il pourrait y avoir une petite boîte dans un coin avec la liste des volontaires pour faire ça et tout...

      En plus, on augmente les chances d'aboutir d'un tel projet, si assez de monde y participe (et ça a l'avantage indéniable de motiver des glandeurs comme moi).

      Ca peut se faire un truc comme ça ? Vous pensez que ça peut marcher ?

  • # On parle bien de la même chose ?

    Posté par  (site web personnel) . Évalué à 1.

    Moi, j'ai un truc qui s'appelle XFree sur ma machine qui ressemble pas mal à ce que vous décrivez : il est très gros, il réinvente beaucoup de choses, il est un bel exemple d'hyperingénierie. Mais à part ça, quand je compare avec vos descriptions et complaintes, j'ai vraiment l'impression qu'on ne parle pas de la même chose.

    Mon XFree, il démarre assez vite, et je ne vois pas trop de problèmes de performance. Les fenêtres s'affichent vite, se déplacent fluidement à l'écran, je n'ai pas de problème lorsque je change leur taille, c'est nickel quoi. C'est même mieux que Windows XP, surtout pour basculer entre différents bureaux (faut dire que les fenêtres d'XP sont plus lourdes graphiquement que mes fenêtres Window Maker, et que la gestion des bureaux est pas excellente). Les vidéos sont bien fluides aussi, c'est sympa. Et puis le tip-top, c'est de pouvoir facilement afficher des fenêtres à distance, par exemple lorsque je me connecte à mon PC en France. Ça rend vert plus d'un utilisateur Windows. Ah, et y'a le clavier aussi, c'est quand même vachement plus facile de créer des majuscules accentuées avec XFree qu'avec Windows.

    Enfin bref, votre brusque dédain et envie pressante de tout jeter à la poubelle me fait hésiter entre l'amusement et l'énervement.

    Vous vous demandez peut-être comment c'est possible ? C'est dû pour l'essentiel à deux choses : j'ai du matériel qui est supporté par XFree (une carte vidéo SiS), et je l'ai bien configuré. Je parie que la majorité des plaintes qui envahissent les commentaires qui me précèdent sont dues à des gens qui ont une config complètement sous-optimisée, avec driver framebuffer et autres lenteurs associées. Autre possibilité, votre carte n'est pas bien supportée par XFree. En tous cas, je suis sûr qu'on peut nettement améliorer la situation avec, dans l'ordre : une bonne configuration, du bon matériel, et de bonnes extensions (XVideo, DRI, etc.)

    • [^] # Re: On parle bien de la même chose ?

      Posté par  . Évalué à 1.

      Je ne suis pas un pro de l'optimisation de XFree86, il ya peut-être des choses à faire, bien que je n'ai jamais rien lu la dessus. Enfin si tu as des liens donne toujours.

      De toute façon même en optimisant ta configuration tu ne réussira jamais à doubler les performances. Au mieux en recompilant XFree pour ton architecture tu augmentera le gain de 20% à 30%, et encore. Et ce n'est pas de 30% qu'il faudrait pour me satisfaire ce serait plutôt de 300% minimum.

      Bien sûr si comme tous les utilisateurs de Window Maker tu ne gardes pas le contenu des fenêtres pendant le redimenssionement et le déplacement de celles-ci tu ne dois effectivement pas trop sentir le ralentissement.

      J'ai eu pendant quelques mois un Celeron 1Ghz avec un SiS et une Mandrake 8.2. Et le déplacement et de redimenssionnement des fenêtres n'est pas d'une vitesse extraordinaire. On est malheureusement loin, très loin de la vistesse de l'interface utilisateur de Windows toutes versions confondues. Et ce n'est pas un troll, chez moi mon PC est exclusivement sur Linux. Mais à mon boulot je travaille conjointement avec des machines de bureau sous Win2K et Linux sur plusieurs machines différentes et le constat est indiscutable sur ce point. Malgrès ses qualités indéniables sur plusieurs autres points la vitesse d'affichage de XFree86 est très très lente.

      Par exempe j'utilise Mozilla Linux, et si j'agrandit la fenêtre le contenu va se redimenssionner au bout de trois secondes. Alors que sur Win2K il faudra 1/50ieme de seconde, le redimenssionement suit le curseur de la souris sans effort. Et Mozilla n'est pas un cas isolé, je peux prendre n'importe qu'elle autre application. Autre exemple si je joue une vidéo avec Xine et que je promène une fenêtre dessus on vois clairement les retards de rafraîchissement.

      Honnêtement refais tes tests en gardant le contenu de tes fenêtres pendant le redimenssionement et le déplacement.

      • [^] # Re: On parle bien de la même chose ?

        Posté par  (site web personnel) . Évalué à 1.

        Par exempe j'utilise Mozilla Linux, et si j'agrandit la fenêtre le contenu va se redimenssionner au bout de trois secondes.

        Euh, mais ça n'a rien à voir là. Ce qui met du temps, c'est mozilla qui recompose la page chteumeuleu pour la nouvelle dimension de fenêtre. Rien à voir avec X11 ou même le window manager.

        • [^] # Re: On parle bien de la même chose ?

          Posté par  . Évalué à 1.

          Je crois que Mozilla utilise XUL, qui lui même utilise GTK, qui lui même utilise la Xlib pour recomposer l'image d'une fenêtre. Alors que sous Windows c'est XUL qui utilise la GDI pour recomposer l'image.

          La vitesse de l'analyseur syntaxique et la vitesse des fonctions XUL doit être un peu prêt équivalente sous Windows et Linux, puisque le code est identique.

          Donc si Mozilla Linux met deux secondes à redessiner une fenêtre là ou Windows met 1/25 de secondes la différence vient bien de la lenteur de XFree86 !

          J'ai pris l'exemple de Mozilla car c'est l'application multi plate-forme par excellence.

          • [^] # Re: On parle bien de la même chose ?

            Posté par  . Évalué à 1.

            Je crois que Mozilla utilise XUL,
            oui
            qui lui même utilise GTK,
            non, rien à voir. Gtk+ dans Mozilla, c'est juste l'embed (un mot français?) dans les applis en utilisant les widget gtk dans la page.

            qui lui même utilise la Xlib

      • [^] # Re: On parle bien de la même chose ?

        Posté par  (site web personnel) . Évalué à 1.

        Bien sûr que je garde le contenu des fenêtres lorsque je les déplace, et c'est à vue de nez aussi performant sous Windows XP que sous Slackware 8.0.

        Par contre je ne garde pas le contenu des fenêtres lorsque je redimensionne. Ça sert qu'à faire chauffer le CPU, et sur un portable, ça me gonfle. Ça m'a toujours gonflé en fait, je trouve ça porc, donc je m'en sers pas.

        D'autre part :

        * Mon CPU est un Celeron 800 MHz
        * Je n'ai pas dit que X était plus performant que Windows, mais que pour l'utilisation que j'en fais (et qui exclut notamment la 3D), les performances des deux systèmes me conviennent et sont équivalentes.
        * Certaines fonctionnalités de X ont un coût en performance, mais je trouve que vous êtes tous beaucoup trop prêts à jeter le bébé avec l'eau du bain.
        * Introduire X à plus bas niveau dans l'architecture de l'OS, c'est augmenter les risques d'instabilité; j'ai toujours un terminal virtuel qui tourne en plus d'X, et j'ai bien souvent pu tuer X là où j'aurais dû rebooter avec une architecture plus intégrée à l'OS.

        • [^] # Re: On parle bien de la même chose ?

          Posté par  . Évalué à 1.


          Bien sûr que je garde le contenu des fenêtres lorsque je les déplace, et c'est à vue de nez aussi performant sous Windows XP que sous Slackware 8.0.

          Tu dois avoir le nez bien long ;-)
          Bien sûr c'est acceptable et utilisable. Mais le déplacement des fenêtres est plus lent sur XFree86.


          Par contre je ne garde pas le contenu des fenêtres lorsque je redimensionne. Ça sert qu'à faire chauffer le CPU, et sur un portable, ça me gonfle. Ça m'a toujours gonflé en fait, je trouve ça porc, donc je m'en sers pas.

          Ah voilà tu ne goutes donc pas à tous les plaisirs de XFree :-)
          Si le déplacement des fenêtre est lent, ce n'est rien à côté du raffraîchissement du contenu des fenêtres.


          Je n'ai pas dit que X était plus performant que Windows, mais que pour l'utilisation que j'en fais (et qui exclut notamment la 3D),les performances des deux systèmes me conviennent et sont équivalentes

          Les performances des systèmes oui, mais celles de l'interface utilisateur graphique non. Les performances 3D sont bien meilleures que les performances 2D, surtout grâce au DRI.


          Certaines fonctionnalités de X ont un coût en performance, mais je trouve que vous êtes tous beaucoup trop prêts à jeter le bébé avec l'eau du bain.

          L'objet de l'article n'est pas de jetter XFree, mais d'optimiser ces quelques lacunes, pour pouvoir avoir un bureau fluide et rapide.

          • [^] # Re: On parle bien de la même chose ?

            Posté par  (site web personnel) . Évalué à 1.

            Tu dois avoir le nez bien long ;-)
            Bien sûr c'est acceptable et utilisable. Mais le déplacement des fenêtres est plus lent sur XFree86.


            Ah voilà tu ne goutes donc pas à tous les plaisirs de XFree :-)
            Si le déplacement des fenêtre est lent, ce n'est rien à côté du raffraîchissement du contenu des fenêtres.

            Arrete de raconter des conneries, ces fonctionnalités sont lentes partout, que ce soit sous win ou x. J'ai beau avoir une athlon 2000+, c'est le premier truc que je désactive quand j'arrive sur un ordi.


            L'objet de l'article n'est pas de jetter XFree, mais d'optimiser ces quelques lacunes, pour pouvoir avoir un bureau fluide et rapide.

            Donc tu vas les aider ou tu es juste ici pour raler sur des problemes qui n'existe que dans ta tete?

            • [^] # Re: On parle bien de la même chose ?

              Posté par  . Évalué à 1.


              Arrete de raconter des conneries, ces fonctionnalités sont lentes partout, que ce soit sous win ou x. J'ai beau avoir une athlon 2000+, c'est le premier truc que je désactive quand j'arrive sur un ordi.


              Ces fonctionnalités ne sont pas lentes partout. Effectivement si tu désactives l'affichage du contenu pendant le déplacement et le redimenssionement des fenêtres, tu ne peux pas t'en rendre compte ! Fait des tests tu verras bien.

              Ecoute j'ai au boulot deux machines cote a cote :

              - une sous Linux Mandrake 9 avec un Pentium III 600 et une ATI Rage XL AGP 2X et 128Mo de RAM et XFree86 4.2.1, et 128 Mo de RAM
              - une sous Win2K SP3 avec un Pentium II 400 et une ATI 3D RAGE Pro AGP 3X et 300 Mo de RAM.

              Les fenetres affichent le contenu pendant leur déplacement et leur redimenssionement sur les deux systèmes.

              Avec Mozilla 1.1 tournant sur les deux machines. C'est sans appel alors que XFree met peu plus d'une seconde pour réafficher le contenu, la GDI met 1/10 de seconde. Et je peux prendre une console ou un editeur de texte c'est pareil.

              Ecoute mon gars j'ai d'un coté ce que tu me dis et de l'autre ce que je vois.

              Donc tu vas les aider ou tu es juste ici pour raler sur des problemes qui n'existe que dans ta tete?
              Arrete de fermer les yeux, et lit les commentaires d'Emmanuel Fusté un peu plus haut, qui sont très très intéressants.

              Ne t'enfermes donc pas dans tes préjugés. Moi aussi j'aimerai que XFree soit plus rapide. Et je sais de quoi je parle j'ai déjà programmé la XLib et Windows.
              ( http://linux.tlk.fr(...) ). Pourquoi pas les aider. Je pourrai commencer à faire quelques documentations sur XFree, c'est un bon début !!

    • [^] # Re: On parle bien de la même chose ?

      Posté par  . Évalué à 1.

      Enfin bref, votre brusque dédain et envie pressante de tout jeter à la poubelle me fait hésiter entre l'amusement et l'énervement.

      Moi, je dirai la rigolade...

      Il a testé cela avec les pilotes propriétaires de Nvidia, le truc qui génère le plus de bruit à l'heure actuelle sur un peu près tous les forums.

      Enfin, on passe le temps comme on peut...

      PK

      • [^] # Re: On parle bien de la même chose ?

        Posté par  . Évalué à 1.

        C'est clair qu'au mieux de passer de temps à discuter si oui ou non XFree est assez rapide on ferait mieux de mettre le nez dans le code et d'optimiser :-)

        Je n'ai jamais utilisé les pilotes de NVidia je n'ai eu que des ATI, Matrox et SiS.

        Les pilotes NVidia sont peut-être plus optimisés, mais sont loger au même niveau pour ce qui est de la conception. Si tu déplaces une fenêtre au dessus de cinq autre fenêtres ton serveur devra se prendre 500 000 requêtes par seconde dans la figure pour avoir des déplacements fluide, donc bonne chance mon gars.

        • [^] # Re: On parle bien de la même chose ?

          Posté par  . Évalué à 1.

          Si tu déplaces une fenêtre au dessus de cinq autre fenêtres ton serveur devra se prendre 500 000 requêtes par seconde dans la figure pour avoir des déplacements fluide, donc bonne chance mon gars

          ce qui pourrait expliquert entre autre la lenteur de Gimp sur les Hautes résolutions!
          un vrai calvaire arf!


          A+

        • [^] # Re: On parle bien de la même chose ?

          Posté par  . Évalué à 1.

          ce qui pourrait expliquer; entre autre, la lenteur du pov GIMP sur les Hautes Resolutions! arf!
          dire qu'on lui tapaient dessus en pensant que c t sa faute! :)

          a+

  • # E17 et Evas

    Posté par  . Évalué à 1.

    J'ai p-e (même surement) pas tout compris, mais y'a pas Enlightenment qui essait d'améliorer les choses avec Evas? Je crois que ca va utiliser OpenGL, ce qui va contourner d'une sorte le manque de perfomance 2D


    Quelqu'un pour confirmer/réfuter/commenter?

    Emmanuel ?

    • [^] # Re: E17 et Evas

      Posté par  (site web personnel) . Évalué à 1.

      Evas va utiliser ce qu'il trouve pour accélérer le rendu, entre autres OpenGL. L'avantage est que si il n'y a pas d'opengl il y aura des solutions "moins accélérées" de secours.

      Le problème est que evas est loin d'être écrit, pour l'instant je crois qu'il n'y a qu'un seul mode de rendu.

      • [^] # Re: E17 et Evas

        Posté par  . Évalué à 1.

        Si je me rappelle bien, Evas est fini (ou presque).
        Ce sont d'autres "composants" d'e17 qui ne sont pas finis.

Suivre le flux des commentaires

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