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 !"
Journal Benchs QT VS Cairo
23
oct.
2006
# en revanche...
Posté par plic . Évalué à 10.
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: en revanche...
Posté par tanguy_k (site web personnel) . Évalué à 2.
[^] # Re: en revanche...
Posté par Olivier Serve (site web personnel) . Évalué à 10.
[^] # Re: en revanche...
Posté par Jerome Herman . Évalué à 10.
[^] # Re: en revanche...
Posté par ☂ Tramo . Évalué à 9.
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 zerbro . Évalué à 8.
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 Raphaël G. (site web personnel) . Évalué à 9.
- 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 zerbro . Évalué à -4.
- 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 Raphaël G. (site web personnel) . Évalué à 8.
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 liberforce (site web personnel) . Évalué à 2.
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 Marc Poiroud (site web personnel) . Évalué à 7.
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 Julien MOROT (site web personnel) . Évalué à 5.
À 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 Olivier Serve (site web personnel) . Évalué à 4.
[^] # Re: en revanche...
Posté par Glorbouille . Évalué à 5.
- 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 qdm . Évalué à 2.
[^] # Re: en revanche...
Posté par Olivier Serve (site web personnel) . Évalué à 9.
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 zerbro . Évalué à -1.
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 Johann Ollivier-Lapeyre (site web personnel) . Évalué à 7.
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 Thomas Douillard . Évalué à 6.
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 Snark_Boojum . Évalué à 2.
[^] # Re: en revanche...
Posté par Maxime (site web personnel) . Évalué à 3.
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 Olivier Serve (site web personnel) . Évalué à 10.
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 Olivier Serve (site web personnel) . Évalué à 5.
[^] # Re: en revanche...
Posté par zerbro . Évalué à 3.
[^] # Re: en revanche...
Posté par Olivier Serve (site web personnel) . Évalué à 4.
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 Aldoo . Évalué à 1.
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 zerbro . Évalué à 4.
+ 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 Aldoo . Évalué à 4.
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 zerbro . Évalué à 3.
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 Aldoo . Évalué à 2.
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 zerbro . Évalué à 3.
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 Aldoo . Évalué à 3.
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 zerbro . Évalué à 2.
[^] # Re: en revanche...
Posté par Aldoo . Évalué à 1.
Donc peut-être qu'à force que les utilisateurs gueulent, ils avaient changé le comportement par défaut...
[^] # Re: en revanche...
Posté par Olivier Serve (site web personnel) . Évalué à 6.
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 ☂ Tramo . Évalué à 1.
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 zerbro . Évalué à 4.
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 ☂ Tramo . Évalué à 10.
- 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 Smarter . Évalué à 3.
Ca vous changera la vie :)
[^] # Re: en revanche...
Posté par Mark Havel . Évalué à 5.
[^] # Re: en revanche...
Posté par Guillaume . Évalué à -1.
...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 dcp . Évalué à 4.
- 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 tipote . Évalué à 10.
[^] # Re: Collaboration
Posté par Snark_Boojum . Évalué à 3.
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!
[^] # Re: Collaboration
Posté par marseillais (site web personnel) . Évalué à 3.
# En développement
Posté par el_mickey . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: En développement
Posté par Raphaël G. (site web personnel) . Évalué à 2.
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 el_mickey . Évalué à 5.
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 Beretta_Vexee . Évalué à 7.
[^] # Re: En développement
Posté par mobutu . Évalué à 7.
[^] # Re: En développement
Posté par dinomasque . Évalué à 5.
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 20 ans !
[^] # Re: En développement
Posté par mobutu . Évalué à 2.
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 Snark_Boojum . Évalué à 5.
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 ナイコ (site web personnel) . Évalué à 4.
Oui, ben en même temps... "Zack Rusin, développeur de chez Trolltech"... Tu t'attendais à quoi ;-) ?
[^] # Re: Ça fait peur...
Posté par Amand Tihon (site web personnel) . Évalué à 5.
[^] # Re: Ça fait peur...
Posté par Snark_Boojum . Évalué à 1.
[^] # Re: Ça fait peur...
Posté par cosmocat . Évalué à 2.
[^] # Re: Ça fait peur...
Posté par Snark_Boojum . Évalué à 2.
Il y a peut-être quelqu'un sur linuxfr qui connaît bien le code de cairo (ou traîne souvent sur #cairo *g*), et qui sait qu'il y a certains endroits dans le code pas optimisés du tout, sur lesquels un peu de travail va tout de suite faire gagner beaucoup au niveau performances.
Bref, j'insiste : ma question n'est pas si bête :-)
[^] # Re: Ça fait peur...
Posté par liberforce (site web personnel) . Évalué à 5.
http://mail.gnome.org/archives/performance-list/2006-October(...)
De rien :-)
[^] # Re: Ça fait peur...
Posté par Snark_Boojum . Évalué à 2.
[^] # Re: Ça fait peur...
Posté par Christophe Fergeau . Évalué à 3.
[^] # Re: Ça fait peur...
Posté par Amand Tihon (site web personnel) . Évalué à 7.
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 Christophe Fergeau . Évalué à 4.
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 EmmanuelP . Évalué à 2.
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 dinomasque . Évalué à 3.
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 20 ans !
# énooooorme :D
Posté par soulflyb (Mastodon) . Évalué à 8.
j'adore cette fin :D
# A propos de Qt4 et de FreeNX (ou X en remote)
Posté par Frédéric COIFFIER . Évalué à 9.
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 Mark Havel . Évalué à -3.
[^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)
Posté par Fritz (site web personnel) . Évalué à 4.
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 Frédéric COIFFIER . Évalué à 5.
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 Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
[^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)
Posté par Mark Havel . Évalué à 3.
Dans l'immédiat, c'est gênant mais je crois qu'on est tous d'accord pour ne pas utiliser de versions non finalisées en production.
[^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)
Posté par Oscar Blumberg . Évalué à 0.
[^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
[^] # Re: A propos de Qt4 et de FreeNX (ou X en remote)
Posté par Pinaraf . Évalué à 6.
# La suiteuh !
Posté par Jean Roc Morreale . Évalué à 6.
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 Nicolas Blanco (site web personnel) . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.