Journal Benchs QT VS Cairo

Posté par .
Tags : aucun
1
23
oct.
2006
Zack Rusin, développeur de chez Trolltech et dev kde, vient de publier quelques comparatifs de performances vectorielles entre QT 4.3svn et Cairo 1.2.5. Le constat :

- QT est 5 à 6 fois rapide que Cairo en passant par Xrender
- QT avec le backend OpenGL est plus de 6 plus rapide qu'avec Xrender
- QT avec xrender est plus rapide que Cairo utilisant Glitz (opengl)
- QT opengl est un gazillion de fois plus rapide que Cairo xrender/glitz

Pour admirer les graphiques en couleur c'est par là :
-> http://zrusin.blogspot.com/2006/10/benchmarks.html

Lien à sortir la prochaine fois que vous voyez un "pourquoi trolltech n'utilise pas Cairo ? c'est de la duplication inutile d'effort !"
  • # en revanche...

    Posté par . Évalué à 10.

    "pourquoi Cairo n'utilise pas QT ? c'est de la duplication inutile d'effort !"

    ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

    • [^] # Re: en revanche...

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

      pfff parceque Qt c'est du C++ et c'est tout pourrie, le C c'est mieux: c'est bcp plus léger en memoire et c'est plus rapide !
      • [^] # Re: en revanche...

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

        C'est pour ça que Gnome est si léger et rapide comparé à KDE...
        • [^] # Re: en revanche...

          Posté par . Évalué à 10.

          Et comme en plus il est intuitif grace au génie ergonomique de Miguel de Icaza
          • [^] # Re: en revanche...

            Posté par . Évalué à 9.

            C'est vrai, il n'y a qu'à voir la merveille qu'est leur file picker (enfin, à la base c'est celui de GTK+, mais ça devient de facto celui de Gnome...) pour comprendre à quel point les développeurs Gnome sont des références en matière d'ergonomie !
            D'ailleurs, ce bijou d'intuitivité est tellement populaire qu'il fait couler beaucoup d'électrons, par exemple chez les utilisateurs de Firefox :
            http://kb.mozillazine.org/Ui.allow_platform_file_picker
            http://konquefox.free.fr/index.html#trick_filepicker
            • [^] # Re: en revanche...

              Posté par . Évalué à 8.

              Ah... Et qu'est ce qu'il a de si "pas intuitif" le selectioneur de fichier de GTK ?

              Vraie question, je ne vois pas ce qu'il a de moins que celui de windows/KDE : il propose les memes options (nom du fichier, un navigateur pour les repertoire, le type de fichier, plus de racourcis type "bureaux", "repertoire perso"). Sauf que je le trouve mieux foutu (question de gout tout ca...) car il est tres proche de nautilus. Ce qui fait qu'on est moins perdu et qu'on sait l'utiliser tres simplement sous gnome.

              Donc, a part lancer un vieux de troll inutil, ininteressant et non constructif sur le selecteur de fichier, ou est le probleme de celui de GTK ?
              • [^] # Re: en revanche...

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

                Au nombre de mes complaintes (pas taper, c'est mon avis perso, vous pouvez être contre !)
                - Nom re-nomage des fichiers listés dedans directement
                - Pas d'accès au propriétés du fichier (pour le rendre exécutable si nécessaire par exemple)
                - Déconnexion du monde unix (Soit le bureau, soit le home, soit le /) mais sous des noms bizarres c'est déroutant...
                - clique nécessaire pour simplement changer de répertoire par défaut
                - clique nécessaire pour choisir une autre extension (par ex dans gimp)
                - sélection multiple a chier
                - non support des urls comme fichier (pardon c'est une "feature" kde tout ça)

                Bon j'en oublie, faudrais pas trop être méchant.

                J'ai qu'une seule chose a dire cette boite a la con gtk elle sux !
                (et c'est une des raisons qui m'a fait virer 90% de toutes les applications gtk ou qui utilise cette boite)

                ps : je parle même pas de la polution du ~/.gconf* et de ~/tmp/orbit-nomuser ni dans le /tmp

                Bref, le C c'est peut-être rapide quand il s'agit de gcc et autre, mais dans le cas des boites d'ouverture/sauvegarde de fichier gtk c'est pas une réussite !

                ps2 : je ne parlerais pas de gnome, vous aurez tous deviné que je ne suis pas en accord avec la conception de l'ergonomie de Miguel de Incaza (erf, dsl pour l'orthographe si je me suis planté)
                • [^] # Re: en revanche...

                  Posté par . Évalué à -4.

                  Ouai, tu es du genre a dire c'est de la merde quand ca te convient pas a toi personnellement. Car tout ce que tu cites dans tes complaintes, moi, ca me gene absolument pas, et je n'en ai pas la moindre utilité :

                  - Nom re-nomage des fichiers listés dedans directement

                  Bah oui, c'est une boite de dialogue pour enregistrer un fichier, pas un explorateur de fichier complet. Ca me permet juste de définir le nom de ce que je veux enregistrer, c'est fait pour ca...

                  - Pas d'accès au propriétés du fichier (pour le rendre exécutable si nécessaire par exemple)

                  Pareil que ci-dessus, ca me sert a rien. Pour gérer ca, j'utilise le term ou nautilus.

                  - Déconnexion du monde unix (Soit le bureau, soit le home, soit le /) mais sous des noms bizarres c'est déroutant...
                  La j'ai pas du tout compris ce que tu voulais dire. Et au contraire, ca colle bien a unix : ca fait qu'une seule chose et bien :)

                  - a propos des clics.
                  Moi je trouve ca plutot agréable d'avoir juste une petite boite la plupart du temps. Le 1/5eme du temps ou j'ai besoin de plus, je clique. C'est pas la mort...

                  - sélection multiple a chier
                  Qu'est ce que tu veux faire d'une selection multiple dans une boite de dialogue pour enregistrer un fichier ? Si tu parles pour "ouvrir un fichier" dans une appli. Je n'ai encore jamais tenté de le faire. Soit ca marche comme partout ailleur, soit ca marche pas du tout. La, je peux concevoir que ca puisse manquer.

                  - non support des urls comme fichier (pardon c'est une "feature" kde tout ça)
                  Oui, moi ca me gene pas du tout, au contraire... Si je veux ouvrir une url, j'ouvre une url, pas un fichier. Philosophie unix tout ca ;)

                  Et la polution dont tu parles, je m'en fous comme de ma première disquette. C'est invisble a l'utilisation.

                  Bref, KDE te convient, c'est tant mieux. Tout ce que tu trouves fantastique me polue mon environement, et la simplicité que j'aime te freine dans ton utilisation. Les gouts et les couleurs...

                  Mais bon, si tu veux, on peut relancer un troll gnome/KDE, ca fait longtemps que j'en ai pas croisé un :)
                  • [^] # Re: en revanche...

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

                    - Nom re-nomage des fichiers listés dedans directement

                    Bah oui, c'est une boite de dialogue pour enregistrer un fichier, pas un explorateur de fichier complet. Ca me permet juste de définir le nom de ce que je veux enregistrer, c'est fait pour ca...


                    Utilité pratique :
                    Je suis sur (mon ftp chez free|/var/www/html), je veux sauver le fichier index.php dedans comme un gorret, mais j'ai pas envie de prendre un rique que ça fasse tout foirer, donc je veux renommer l'original en .bak avant de sauver.

                    Ben dans un cas tu renomme, dans l'autre tu sort un terminal.

                    Bon c'est qu'un exemple parmi tant d'autre...
                    • [^] # Re: en revanche...

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

                      J'ai peut être pas tout compris, mais je dirais
                      1. Tu ouvres le répertoire en ftp via nautilus "Connecter au serveur"
                      2. Tu le renommes
                      3. Tu fais un drag and drop de ton fichier à déposer

                      Depuis le passage au mode spacial, tout est fait pour faciliter le drag and drop au maximum.

                      Après effectivement, une fois qu'on a ses habitudes tout ce qui semble différent est "de la merde". Je ne dis pas que le sélecteur n'est pas exempt de défauts (effectivement les propriétés, ça peut être intéressant), mais là on est plus proche de la philosophie unix: on fait une chose et bien. Alors oui il y a des ratés (ne pas avoir un champ texte avec l'adresse du fichier), mais ça s'arrange.
                      • [^] # Re: en revanche...

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

                        Depuis le passage au mode spacial, tout est fait pour faciliter le drag and drop au maximum.

                        Et sous Konqueror, tu fais CTL+MAJ+L pour scinder ta fenêtre, tu "drag'drop" sans le « mode spacial fait pour faciliter le drap and drop ».

                        /me veux pas lancer de troll, mais Gnome est encore loin de simplicité de KDE ... << Avis _trés_ personnel !
                        • [^] # Re: en revanche...

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

                          J'ai beau etre pro-KDE, le CTRL+MAJ+L (bien que j'utilise cette fonctionnalité tous les jours) c'est franchement un mauvais exemple pour dire que KDE c'est facile. Car en dehors des informaticiens, la majorité des personnes se souviennent à peine des raccourcis clavier pour couper/copier/coller.
                          À mon avis parler de la transparence réseau des KIO bien plus poussée et performante que Gnome-VFS est un meilleur exemple :)
                          • [^] # Re: en revanche...

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

                            Sauf que justement c'est dans les menus aussi et qu'on peut même avoir les boutons idoïnes dans une jolie toolbar...
                            • [^] # Re: en revanche...

                              Posté par . Évalué à 5.

                              Je dirai mm plus:
                              - c'est dans les menus
                              - c'est dans l'extra tool bar
                              - c'est dans les raccourcies clavier
                              - c'est accessible via un clic droit dans la barre d'état (ce que j'utilise le plus souvent)
                              - Cela peut être mm un mouvement de souris via khotkeys
                              - ... (j'en oublie?)

                              C'est pas pour troller, j'ai juste besoin d'être rassuré :
                              Supprimer des options sous prétexte que les neuneus ne sauraient pas s'en servir, ce ne serai pas plutôt parceque les dev gnome ne savent pas comment les rendres facilement accessible?
                              Blague à part, je pense que le gros avantage de kde, c'est l'utilisation du c++ dans QT qui permet une vrai souplesse dans l'implantation des fonctionnalités. (je dit ça, je n'en sais rien, je ne pratique que le c).
                        • [^] # Re: en revanche...

                          Posté par . Évalué à 2.

                          Ah ben je viens de découvrir une fonction. Merci !
                      • [^] # Re: en revanche...

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

                        mais là on est plus proche de la philosophie unix: on fait une chose et bien

                        Je dirais plutôt qu'il n'en fait pas le quart et qu'en plus il le fait mal.
                        Ceci est un message purement trollistique
                    • [^] # Re: en revanche...

                      Posté par . Évalué à -1.

                      je veux sauver le fichier index.php dedans comme un gorret


                      Elle est la la différence ^^. Gnome t'oblige a être propre et réfléchi :)

                      Marrant, on peut voir sur les scores des commentaires que les suporters de KDE sont en force sur ce fil.
                      • [^] # Re: en revanche...

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

                        Ou que simplement que cette boite est tellement pourri que meme des gnomistes ou utilisateurs d'apps GTK petent les plombs dessus.

                        Avec cette critique qui reviens tres régulierement (ici, tests ...) , les plussages/moinssage sur ce fil.... mais on ne se remet pas en question, c'est forcement une caballe de fanboys de KDE ;)

                        De toute maniere, Portland arrive, et on aura (sauf sous gnome) des boites de dialogue correct avec Gimp, Inkscape, .... et les gnomistes pourront profiter de leurs jolies boites pour amarok, k3b...
                      • [^] # Re: en revanche...

                        Posté par . Évalué à 6.

                        Exact, genre la différence vient peut être du fait qu'on a l'habitude de ranger nos fichiers comme bon nous semble (pas nécessairement comme des gorets, mais avec une logique à nous), en tant qu'informaticiens.

                        Alors que la "tendance" qu'on peut observer, c'est que l'utilisateur est plus ou moins guidé pour ranger ses fichiers dans "ma musique", "mes images", ... En suivant ce genre de convention, tu as déja ces répertoires accessibles facilement de base dans la boite, et tu te crées d'autres raccourcis pour tes autres répertoires "standards".

                        L'hypothèse de gnome est que ça suffit pour la plupart des cas d'utilisation, particulièrement pour un utilisateur lamda, j'imagine. Pour nous informaticiens qui avons nos habitude, c'est peut être un peu plus dur de "rentrer dans les cases", à la fois par habitude et parce qu'on est confronté à plus de situations différentes qu'un utilisateur lambda.
                        • [^] # Re: en revanche...

                          Posté par . Évalué à 2.

                          Personnellement, quand je me retrouve face à un sélecteur de fichiers, mon réflexe c'est d'ouvrir un terminal pour repérer où je veux poser le truc, en créant éventuellement des répertoires et/ou en déplaçant des fichiers qui gênent. :-)
                  • [^] # Re: en revanche...

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

                    L'autre jour j'ai clické sur creer un dossier sans faire exprès...
                    Et j'ai pas pu le supprimer :/
                    C'est quand même pas top top pour certains details. Comme l'incapacité à renomer aussi.
              • [^] # Re: en revanche...

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

                1. Pas de champ de saisie du chemin direct. Il y a bien une fenêtre qui apparaît quand on tape '/' (et allez, encore une, vive la simplicité), mais on est obligé de taper le chemin complet depuis la racine et pas depuis le répertoire affiché.

                2. Cette même petite fenêtre, dans sa volonté d'assister l'utilisateur impose un temps d'attente pour afficher une liste de choix. Pire, si je tape 'usr', j'ai la surprise de voir que ce con me met '/usr/src/', ce que je n'ai _jamais_ demandé.

                3. Quand on a réussi à taper /usr/bin, la fenêtre met 3 plombes à afficher tous les fichiers.

                4. Si je tape /usr/bin/kate, râle parce qu'il lui faut un répertoire. Donc effaçage puis attente 30s que la liste apparaisse puis recherche de 'kate' là-dedans...

                C'est peut-être mieux pour l'utilisateur de base, mais pour moi c'est une horreur absolue à utiliser.
                • [^] # Re: en revanche...

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

                  J'ai oublié de mentionner que le raccourci magique '/', il faut le trouver quand même...
                • [^] # Re: en revanche...

                  Posté par . Évalué à 3.

                  Comme beaucoup d'utilisateurs insistaient pour pouvoir entrer le chemin complet, cela a été ajouté dans la dernière version de GTK (utilisée par gnome 2.16). Plus besoin de racourcis clavier.
                  • [^] # Re: en revanche...

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

                    Mais les autres points ?

                    On peut partir du répertoire courant ?
                    La complétion envahissante est désactivée/able ?
                    L'affichage d'un gros répertoire ne bloque plus la fenêtre pendant 30 secondes ?
                    On peut taper directement le nom de l'exécutable sans avoir à chercher parmis les 1559 autres ?
                    • [^] # Re: en revanche...

                      Posté par . Évalué à 1.

                      Je crois que tu as bien résumé les vraies lacunes du filepicker de GTK. Le reste c'est des questions de goûts et couleurs, mais pas ça !
                      Bon, je n'utilise pas Gnome, à la limite je m'en fous un peu... sauf qu'il m'arrive malgré tout d'utiliser Firefox et d'être forcé de supporter ça (oui, on peut bidouiller pour avoir le filepicker de KDE, mais ce n'est pas franchement stable... ).

                      Dommage que je ne puisse pertinenter qu'une seule fois !
                    • [^] # Re: en revanche...

                      Posté par . Évalué à 4.

                      Je viens de rentrer chez moi et j'ai regardé :
                      + on peut partir du repertoire courant (en fait, ca fonctionnne exactement comme nautilus, avec les repertoire affichés au-dessus, pour un utilisateur de gnome, c'est tres bien, n'en déplaise aux autres)
                      + la complétion est la mais ne me pose pas le moindre problème (je n'arrive pas a reproduire ce que tu décris, et je n'ai jamais eu de probleme avant)
                      + L'affichage d'un gros répertoire est LE probleme (/usr/bin met bien 5 bonnes secondes pour tout afficher, sur un PC qui a 3 ans)
                      + Je ne sais pas si j'ai bien compris le dernier point, mais si tu es dans le bon repertoire et que tu tapes un nom de fichier, il fait ca qu'il faut...

                      Je persiste a dire que pour un utilisateur de gnome, le selectioneur de fichier est tres bien. Après, qu'il ne plaise pas aux utilisateurs de KDE, tant pi, c'est pas le but :)
                      • [^] # Re: en revanche...

                        Posté par . Évalué à 4.

                        Le problème de la complétion, c'est qu'au lieux de te laisser une liste de choix et te laisser valider explicitement, dès qu'il n'y a qu'un seul choix (par exemple si on tappe "/u"), il va compléter tout seul (en "/usr/"). Donc si emporté dans mon élan je tappe "/" "u" "s"... je me retrouve dans "/usr/src/" contre ma volonté.
                        Ce comportement est peut-être efficace pour qui en a l'habitude, mais il est contraire aux conventions usuelles d'autocomplétion, que ce soit à la mode console, ou à la mode Windows/KDE/Firefox/...

                        Pour ce qui est du choix d'un exécutable, je pense qu'il parle par exemple du choix d'une appli pour ouvrir un fichier depuis Firefox. Admettons qu'on veuille ouvrir avec kate, il serait logique qu'on puisse faire "/usr/bin/kate", entrée, et basta. Ou encore mieux "kate", entrée et basta, vu que "/usr/bin" est dans $PATH. Or non, là on est d'abord obligé d'entrer dans le répertoire, et d'attendre que la liste des fichiers se construise. Beurk.
                        • [^] # Re: en revanche...

                          Posté par . Évalué à 3.

                          Sur l'autocompletion, lorsqu'il n'y a qu'un seul choix, gtk va en effet completer tout seul "/u" en "/usr". Mais si je tape "s", il laisse cette completion (il y a un surlignage qui indique ce qu'on a tapé et ce qui est complété).

                          Pour l'executable, il y a une boite de dialogue en général, qui permet de choisir dans une liste d'application, ou bien d'entrer a la main l'exectutable. Tout marche parfaitement comme on s'y attend. Si on veut parcourir le systeme a la recherche d'un executable, il faut effectivement entrer tout le chemin, ce qui n'est pas illogique, dans ce cas la (sinon il ne fallait pas choisir "parcourir le système", mais l'entrer directement). Ouai, je sais pas si je suis super clair...
                          • [^] # Re: en revanche...

                            Posté par . Évalué à 2.

                            Oui, il laisse la complétion, et c'est bien le problème : aucun autre système de complétion n'a ce comportement !

                            Pour ce qui est du choix de l'application : je ne sais pas pour l'utilisation en général sous Gnome, mais sous Firefox, il propose parfois quelques choix... mais en général les choix par défaut de Gnome, donc des applis Gnome (quand elles sont installées), donc pas celles qui m'intéressent.

                            Outre le fait que n'utilisant pas Gnome, je n'ai pas envie de me faire ch* à configurer cet environnement, il peut arriver n'importe quand de vouloir ouvrir un fichier avec une autre appli que l'habituelle. Donc il serait bien, dans tous les cas, de pouvoir faire ce choix facilement, et sans passer par un dialogue anti-ergonomique.
                            • [^] # Re: en revanche...

                              Posté par . Évalué à 3.

                              Il faudrait que regardes vraiment comment fonctionne le sytème de complétion, il est comme les autres en fait.
                              si tu tapes "/""u""y" il tu proposeras "/usr" avec "sr" surligné, mais quand tu tapes "y", il sera écrit "/uy". Si tu voulais bien "/usr" tu tapais sur tab... Bref, tout est normal...

                              Bref, tous les choix de gnome sont tres cohérents dans l'environnement. A l'exterieur, j'en sais rien, et je dirais meme que je m'en fou en fait : j'utilise gnome, et j'attends que leurs choix soient cohérent a l'interieur de gnome.

                              Si firefox a choisi le selectioneur de fichiers de gnome, c'est un probleme de firefox, pas du selectionneur de fichier, et encore moins de gnome.

                              Bref, c'est sur firefox qu'il faut "gueuler" (pas mechament hein, quand meme...), pas sur gnome ou GTK.
                              • [^] # Re: en revanche...

                                Posté par . Évalué à 3.

                                Bon apparemment le filepicker n'a pas le même comportement chez moi et chez toi donc... (parce que je suis sûr de ce que j'avance pour la complétion !)
                                Donc c'est un faux débat ;-)

                                Maintenant, il serait intéressant de savoir pourquoi ça se comporte bien chez toi ? Un paramètre passé en option par Firefox ? Je ne verrais pas l'intérêt, d'autant plus que la MoFo prétend chercher à harmoniser avec Gnome. Ça doit donc être autre chose.
                                • [^] # Re: en revanche...

                                  Posté par . Évalué à 2.

                                  Vérifie peut etre ta version de GTK. Je parle de gnome 2.16.1 avec GTK 2.10.6 et je n'ai changé aucun paramètre (réglages par défaut de ubuntu edgy).
                                  • [^] # Re: en revanche...

                                    Posté par . Évalué à 1.

                                    Bon, je viens de rentrer chez moi, et effectivement, ça marche comme tu dis. Mais en même temps, je suis aussi passé à Edgy il y a peu.
                                    Donc peut-être qu'à force que les utilisateurs gueulent, ils avaient changé le comportement par défaut...
                              • [^] # Re: en revanche...

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

                                Visiblement, les dévs se sont enfin décidés à corriger ça dans GTK 2.10. Tant mieux. Mais on aura attendu.

                                Bref, c'est sur firefox qu'il faut "gueuler" (pas mechament hein, quand meme...), pas sur gnome ou GTK.

                                Ben non. Firefox utilise GTK. Il semble normal qu'il utilise donc aussi les boîtes de dialogue de GTK.
                              • [^] # Re: en revanche...

                                Posté par . Évalué à 1.

                                Si firefox a choisi le selectioneur de fichiers de gnome, c'est un probleme de firefox, pas du selectionneur de fichier, et encore moins de gnome.

                                Il me semble bien que quand Firefox a commencé à utiliser le sélecteur de fichier natif de GTK, il avait encore un fonctionnement et une apparence standards (similaires aux sélecteurs de fichiers des autres plateformes).
                                Ce n'est que plus tard que les grands pontes de Gnome/GTK ont décidé de passer à leur sélecteur révolutionnaire, qui est par ricochet devenu le sélecteur de Firefox sous Linux.
                                Bref, Firefox a fait le choix d'un sélecteur natif (car en principe c'est celui qui devait le moins déstabiliser l'utilisateur), mais n'a pas choisi explicitement ce sélecteur (et devant le tollé général, ils ont même remis la possibilité d'utiliser leur sélecteur maison, car c'était finalement le moins déstabilisant).
                                • [^] # Re: en revanche...

                                  Posté par . Évalué à 4.

                                  Je disais juste pour dire : firefox utilise GTK, si ca ne convient pas aux utilisateurs de KDE, ce n'est pas la faute de GTK, mais du fait que firefox a choisi GTK... Comment ca je ne suis pas clair ? suivez un peu ! :p

                                  Au debut, GTK avait un selectioneur de fichier minimaliste (a deux colonnes). Tout le monde gueulait pour avoir un autre selecteur de fichier. Ils en ont fait un. Mais aujourd'hui, il ne convient pas aux utilisateurs "non GTK". On ne peut quand meme pas leur en vouloir... Car en tant qu'utilisateur de gnome "only", ca me convient vraiment parfaitement.

                                  Il etait question de faire un firefox en QT a une epoque je crois, ca en est ou ? Comme ca, tout le monde serait content...
                                  En fait, j'aimerais surtout savoir ou en est la séparation du moteur Gecko en une lib, qui ne necessite pas d'installer tout firefox pour avoir un autre navigateur utilisant gecko (comme epiphany)...
              • [^] # Re: en revanche...

                Posté par . Évalué à 10.

                Le problème numéro 1, c'est le nombre de clics et de scrolls nécessaires pour choisir un fichier ou un répertoire :
                - quasiment tout le temps, je dois cliquer sur "Parcourir d'autres dossiers", ça fait déjà un clic inutile : http://konquefox.free.fr/images/screenshot_fileficker_defaul(...)
                - ensuite, les composants graphiques sont tellement bien agencés, que seulement 3,2 noms de fichiers sont affichés par défaut, donc il faut soit scroller à mort, soit redimensionner la fenêtre : http://blog.vojta.name/images/m84-gnome-save-expanded.png

                Autre énormité ergonomique : si on veut choisir le format d'enregistrement, il faut aussi par "Parcourir d'autres dossiers". Je cherche toujours le rapport entre ces deux notions...

                Alors certes, la version de base est simple et concise, mais on fait tellement peu de choses avec qu'à l'usage c'est totalement contre-productif !
                On est bien ici face à un travers important de Gnome : à vouloir simplifier à outrance, on finit par complexifier inutilement...
            • [^] # Re: en revanche...

              Posté par . Évalué à 5.

              Merci pour ces liens qui vont me permettre de me débarrasser de cette saloperie de sélecteur de fichier de Gnome. Je n'ai jamais compris comment une telle... chose pouvait encore être en usage à notre époque. Enfin, en fait, le problème principal, c'est que les utilisateurs de KDE devait se la cogner quand ils utilisaient Firefox et donc par exemple voir les positions des boutons ok et annuler inversées par rapport à ce qu'on trouve dans les menus classiques de KDE, sans oublier qu'on a généralement très envie de mettre les fichiers ailleurs qu'à l'endroit sélectionné par défaut et qu'on perd donc quelques secondes à agrandir la fenêtre pour ça en cliquant sur "je veux aller voir ailleurs"... Bref, je le hais et je vais tout faire pour remédier à la situation le plus vite possible grâce à ces liens.
              • [^] # Re: en revanche...

                Posté par . Évalué à -1.

                Utilisateur de gnome, j'ai souvent les problèmes que vous évoqués (fenêtre par défaut trop petite qu'il faut agrandir à la main pour voir tout le contenu)...
                ...avec les applications kde que je lance.

                Visiblement le problème est dans les deux sens. ^^
                De même, le comportement des applications kde peut être déroutant pour un gnomiste. Je pense notamment à Konqueror avec ses milliers d'options inretrouvables. Ou frustrant comme le lanceur de programmes (alt+F2) qui ne possède pas l'auto-complétion.


                A notre pour konquéror, il est possible d'utiliser les filtres anti-pubs/sats de firefox (cf dans la config filtres adblock). Notamment cette liste d'expressions régulières: http://adblock.free.fr/
    • [^] # Re: en revanche...

      Posté par . Évalué à 4.

      pourquoi Cairo n'utilise pas QT ? c'est de la duplication inutile d'effort !


      - Cairo est un effort communautaire.
      - Qt est un (très très bon) produit de Trolltech qui une fois prêt est offert à la communauté (une des licences est la GPL). Il ne me semble pas que la communauté soit invitée a travailler sur les évolutions de Qt.

      Du coup le développement de Cairo ayant débuté avant que Arthur (le moteur de rendu de Qt) soit officiellement disponible. Les dev de Cairo n'ont pas eu à se poser la question d'utiliser ou non Qt.
  • # Collaboration

    Posté par . Évalué à 10.

    Je me trouvais dans le canal #cairo sur le serveur IRC de freenode quand Carl Worth (responsable de Cairo) et Zack Rusin discutaient de ces mesures, hier. Il était intéressant de voir la conservation franche entre les deux, Carl reconnaissant bien volontiers qu'il y avait encore du travail à faire, et Zack expliquant ses résultats. Comme le précise Zack dans son blog, la prochaine version de Cairo contiendra un nouveau tesselator (algorithme qui transforme un polygone compliqué en petites entités que la couche d'abstraction inférieure - png, xrender, opengl... - sait représenter) qui pourrait bien réduire l'écart. Toujours est-il que Zack est un pro de ces fameux tesselators, et qu'il a proposé à Carl de collaborer sur le sujet.
    • [^] # Re: Collaboration

      Posté par . Évalué à 3.

      Oui, Z.R. parle dans son blog d'un tesselator avec une complexité logarithmique dans qt, ce qui n'est pas le cas dans cairo.

      C'est vrai qu'entre un O(n) et un O(ln(n)), ça fait une grosse différence. Mais ça dépend de la constante du O(), et c'est pour n>>0... je reste ébahi par les résultats!
  • # En développement

    Posté par . Évalué à 1.

    J'avais cru comprendre qu'au début du moins les performances n'étaient pas la priorité pour cairo et que l'optimisation serait facile à faire par la suite. Quelqu'un est plus au courant de la situation ?
    • [^] # Re: En développement

      Posté par . Évalué à 8.

      Ouais ben excuse-moi du peu, mais si ça fait comme pour GNOME, on va devoir attendre la version 4.x ou 5.x pour avoir l'équivalent de la vélocité du KDE 2.x d'antan ... Et je ne parle même pas du KDE 3.5.x actuel car je l'utilise depuis ce matin en lieu et place de GNOME sur ma machine et "par la force des choses", et je suis complètement bluffé : j'ai l'impression d'avoir boosté ma machine. Et ça fait mal à dire quand on est un GNOMineux convaincu :'(

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: En développement

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

        hum, y a pas mal de chose dans kde qui sont mis en cache, c'est carrément époustouflant ce que ça réduis comme temps d'attente ;)

        Par exemple il te permet d'avoir des instances de konqueror en cache (j'en met 2 avec "essayer d'avoir toujours une instance pré-chargée") et ça te permet d'avoir un konqueror instantanément quand tu clique sur l'icône
        (il fait un bête appel dcop qui affiche un des konqueror pré-chargé au lieu de créer un processus complet)

        De plus le système d'architecture de kde fait que toutes les librairies kde sont déjà en mémoire ce qui donne un gain de temps énorme.

        Seul bémol y a encore des petits soucis de race condition, genre konqueror a tendance a s'écrouler si tu lui lance de multiple onglet a charger en parallèle
        (Hum, pas un ou deux pour les mauvaises langues, mais une trentaine, pour remplir toute la barre ;)
      • [^] # Re: En développement

        Posté par . Évalué à 5.

        Tout ce que je demandais etait simplement : est ce que les gars de cairo on fait un truc qui marche dans un premier temps et aprés qui soit facile à optimiser parce qu'on sait ou le faire ?

        Je reconnais que ça peut paraitre débile comme approche mais moi ça me convient. Si on a pas beaucoup de ressources, on fait d'abord quelque chose de bien architecturé et aprés on optimise dessus.

        Pour le reste des composants gnome, j'ai plus l'impression que c'est : on code et aprés on se demande comment optimiser.
        • [^] # Re: En développement

          Posté par . Évalué à 7.

          Cette politique et aussi trés souvant chez Gnome une bonne excuse pour un certain immobilisme, a non c'est trop tôt, on est entraint de construir des fondations, on s'en occupera plus tard ... Les fonctions avancées, l'optimisation et autre ont une facheuse tendance a ne jamais arrivée. Et cela décourage pas mal de monde.
        • [^] # Re: En développement

          Posté par . Évalué à 7.

          En même temps c'est toujours comme ça et dans le mauvais sens de la chose avec les technos crées par des gnomistes. Gstreamer est un veau et a beaucoup de mal avec beaucoup de vidéos là où Xine ou VLC passent très bien.
          • [^] # Re: En développement

            Posté par . Évalué à 5.

            Méfiance méfiance !
            J'ai été estomaqué en installant la beta d'Ubuntu Edgy sur une machine PPC : Totem+Gstreamer est devenu capable de lire des vidéos !
            Et dans plein de formats en plus (mais pas encore autant que VLC qui sait lire les WMV dernière mode).

            BeOS le faisait il y a 15 ans !

            • [^] # Re: En développement

              Posté par . Évalué à 2.

              Je n'ai pas de WMV :)
              Je serais très heureux d'apprendre que Gstreamer devienne parfaitement utilisable avec des vidéos plutôt basiques pourtant. Des améliorations de performances seraient bienvenues aussi, le seeking, c'est pas toujours la joie..
  • # Ça fait peur...

    Posté par . Évalué à 5.

    ... j'ai vu cette entrée de blog et je me suis dit : c'est pas possible!

    Il doit quand même y avoir une énormité quelque part, parce qu'une différence pareille ça semble quand même aberrant.

    J'attends de voir la réponse des développeurs cairo (des développeurs, pas des fanas... je veux des explications techniques, pas des râles de bêtes!).
    • [^] # Re: Ça fait peur...

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

      ... j'ai vu cette entrée de blog et je me suis dit : c'est pas possible!
      Il doit quand même y avoir une énormité quelque part, parce qu'une différence pareille ça semble quand même aberrant.
      J'attends de voir la réponse des développeurs cairo (des développeurs, pas des fanas... je veux des explications techniques, pas des râles de bêtes!).


      Oui, ben en même temps... "Zack Rusin, développeur de chez Trolltech"... Tu t'attendais à quoi ;-) ?
    • [^] # Re: Ça fait peur...

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

      Le second fil de commentaires, un peu plus haut, commence par un message de tipote qui explique justement où se situe la différence, selon Zack. Ah tiens, c'est même expliqué dans son billet, dont le lien est présent dans le journal, mais c'est en anglais, je le reconnais.
      • [^] # Re: Ça fait peur...

        Posté par . Évalué à 1.

        Il n'affirme pas que c'est l'explication, mais seulement que c'est une piste. Nuance. Ma question tient toujours : comment est-ce possible !?
        • [^] # Re: Ça fait peur...

          Posté par . Évalué à 2.

          Je crois que tu te réponds à toi même. Si les mecs qui sont des bêtes dans ce domaine ne peuvent au plus que te donner des pistes de recherche, je vois pas qui va répondre parfaitement à ta question.
    • [^] # Re: Ça fait peur...

      Posté par . Évalué à 3.

      Déjà, une question... Quand tu regardes/imagines une interface graphique, tu vois beaucoup d'endroit où tu dessines un polygone à 100.000 sommets (je sais plus le nb exact que zrusin a utilisé dans son bench) ? Ou tu vois plus des polygones avec une dizaine de sommets (par ex, un bouton c'est un rectangle) + de la transparence et des effets du genre ? Moi j'imagine plutôt le 2nd cas, ce qui rend le bench très artificiel, du moins pour ce qui est fait actuellement avec ces technos de rendu. Mais c'est pas inintéressant quand même ;)
      • [^] # Re: Ça fait peur...

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

        Ah ben non, ton bouton il a des coins arrondis, il faut "tesselater".
        Et dans une appli KDE, il y a plein de boutons partout :)
        Et puis tes fenêtres molles qui se déforment, il faut les "tesselater" aussi.
        Un autre très gros mangeur de polygones, c'est le texte.

        Alors évidemment, zrusin a exagéré. Mais maintenant, il sait que son algo est correct, et qu'il ne risque pas de devoir repasser dessus dans un an parce que les perfs sont à la ramasse.
        • [^] # Re: Ça fait peur...

          Posté par . Évalué à 4.

          A priori, le coin arrondi, tu le tesselate pas, tu dis à Xrender/opengl de te dessiner un arc de cercle (je suis carrément pas sûr de ce que je dis, j'ai jamais creusé la question, mais je le ressens comme ça).
          Et ta fenêtre qui se déforme, tu ne la gère pas du tout avec cairo ou le truc de dessin vectoriel de QT... C'est un bête objet opengl que tu déformes à coup de shaders ou de dieu sait quoi (cairo/qt fait le rendu dans un pixmap en mémoire *non déformé*, et ensuite le serveur X balance ce pixmap représentant la fenêtre complète non déformée à la carte graphique sous forme d'objet opengl, puis fait explique à la CG qu'elle doit déformer cet objet).
          • [^] # Re: Ça fait peur...

            Posté par . Évalué à 2.

            Un autre très gros mangeur de polygones, c'est le texte

            Oui, mais d'une part, il me semble que les glyphes sont mis en cache, donc rendu une seule fois, et d'autre part, ce n'est pas cairo qui effectue le rendu...

            priori, le coin arrondi, tu le tesselate pas

            Si tu passe par un appel à cairo, si, tu dois le tesselater. Après, rien ne t'oblige à passer par cairo pour dessiner un rectangle avec des coins arrondis...

            Sinon, pour cette histoire de benchmark, si le résultat m'a un peu déçu (parce que le benchmark teste un point qui est assez important pour l'utilisation qu'on en fait dans le moteur de tracé de courbe de gnumeric basé sur cairo), je me dis que finalement, c'est plutôt une bonne nouvelle, car potentiellement il y a des cas où cairo peut devenir 40 fois plus rapide, et que je suis convaincu que les développeurs pourront placer cairo au même niveau qu'arthur...
      • [^] # Re: Ça fait peur...

        Posté par . Évalué à 3.

        Quand je regarde l'interface graphique de mon logiciel favori du moment, je vois plein de polygones avec tout plein de sommets : j'utilise Inkscape.

        Et vu la lenteur du logiciel, je suis super intéressé par un éventuel passage à Cairo si ce dernier est bien optimisé et est bien accéléré par ma carte graphique.

        BeOS le faisait il y a 15 ans !

  • # énooooorme :D

    Posté par . Évalué à 8.

    Objectivity aside, Qt rocks. It really does. And if you're using Qt and not using Qt's rendering architecture, everyone should point at you and make fun of you for not having complete and utter trust in me, as the only true graphics ninja and the team of Trolltech's Samurai Graphics Assassins.

    j'adore cette fin :D
  • # A propos de Qt4 et de FreeNX (ou X en remote)

    Posté par . Évalué à 9.

    Je ne sais pas s'il y en a parmi vous qui utilisent fréquemment FreeNX pour se connecter à distance (ou même X en remote sur un réseau local).
    J'ai eu l'occasion de tester Qt4 et j'ai eu l'occasion de le tester dans une session FreeNX et tout ce qui est graphique rame énormément.

    En effet, en ce moment, j'ai toute une session KDE3 qui tourne sans problème. Même un Gimp pourrait être utilisable dans ces conditions (pas pour dessiner mais pour utiliser des filtres). Même avec Inskape, je peux déplacer un carré normalement.

    Mais si j'utilise les applis de démos de Qt4.2, ça rame énormément. L'appli avec les souris qui mange le fromage (cf Graphics View : http://doc.trolltech.com/4.2/qt4-2-intro.html ) me prend 100% CPU sur la machine distante et des souris figées sur la machine locale.
    Vu que KDE4 va vraisemblablement utiliser toutes ces nouveautés, je me demande si KDE4 sera utilisable en distant (et si ce n'est pas le cas, ce serait une grosse perte).
    • [^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)

      Posté par . Évalué à -3.

      Ouais enfin, il me semble que la très grande majorité des utilisateurs ne passent pas par du réseau pour utiliser leur KDE donc je tempèrerais quelque peu la taille de la perte. Mais on peut aussi soupçonner soit un gros bug dans l'une des deux applis, soit une optimisation qui manque quelque part aussi. Cela peut donc s'améliorer rapidement au cours d'un patch quelque part.
      • [^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)

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

        Je ne suis pas d'accord, l'utilisation via le réseau est très importante, même si peu de gens l'utilisent...

        Ne pas la prendre en compte va empêcher l'utilisation d'applis kde dans des conditions potables sur des terminaux légers. Etant plutôt du xfce, je trouve quand même dommage de devoir se priver de certaines applications de kde parce que qt4 empêche une utilisation aisée en réseau!
      • [^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)

        Posté par . Évalué à 5.

        On ne me fera pas croire que la prise en main à distance de PC Windows dans une entreprise, c'est anecdotique.
        Combien d'entreprises fournissent un accès à distance à leurs employés qui sont en déplacement ou en astreinte ?
        Sachant que pour Windows, les logiciels pour réaliser cela coûtent une petite fortune !

        Je ne pense pas que Windows Vista sera un obstacle à ça.

        Comment expliquer alors qu'avec KDE4, on ne puisse plus faire ça sachant que c'est une caractéristique de X depuis près de 20 ans et que grâce à FreeNX, on a les mêmes performances qu'avec des outils commerciaux pour Windows ?

        A l'heure où Linux entre sur le bureau des entreprises, il serait dommage de se fermer cette porte...
    • [^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)

      Posté par . Évalué à 6.

      Je penche pour l'absence de support de XRender ou de l'OpenGL dans FreeNX.
  • # La suiteuh !

    Posté par . Évalué à 6.

    Zack Rusin vient de publier un nouveau post en réponse à toutes les questions (ou conneries) qui ont été posées -> http://zrusin.blogspot.com/2006/10/disappointing.html

    Que Qt 4.3 soit aussi performant m'inspire confiance pour Plasma, est-ce la fin des jolies applets karamba bouffeuses de cpu ? Je m'enthousiasme encore de voir que je peux gagner en perfs et confort d'utilisation sans avoir à changer mon vieux système ni mes habitudes ^^
    • [^] # Re: La suiteuh !

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

      J'adore complètement cette réponse :

      Q: But what if something else would be faster than Qt? Would you post results then?

      A: Well, I don't exhibit self-destructive behaviour so no, of course not. I'd fix my code to make sure it's faster and then I'd post them. This is how this works. If there's anything, and I do mean anything that Qt is slower at than any other vector graphics framework, be it Microsoft's WPF, Java2D or Cairo we'll fix Qt and make sure it's either faster or at least at the same level. Like I said, I'd love to be able to test Qt against something else, rather than Qt itself. If you can provide me a benchmark that shows Qt slower at anything in comparison to any other vector graphics framework, I'll make sure that it's not the case for long.

Suivre le flux des commentaires

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