coup de gueule

Le Fri, 27 Aug 2004 00:58:55 +0200, Emmanuel Florac a écrit :

Environ 10 secondes entre le clic sur l'icône et l'affichage de la
fenêtre au complet sur mon fringuant PIII 550/256 Mo.

J'ai oublié de préciser que j'avais Firefox, Sylpheed-claws-GTK2 et pan
d'ouvert (plus tout le bazar habituel en tâche de fond, bien sûr).

--
In girum imus nocte ecce et consumimur igni

On 2004-08-26, Benjamin FRANCOIS <kwyxz@kwyxz.org> wrote:

Sam Hocevar s'est exprimé en ces termes:

Dans le XVe en plus.

T'es sûr que c'est abordable pour un thèsard, ce genre-là ?

Qui a dit que c'était le thésard qui payait ?

--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.

Ah? Je n'ai pas de 233 sous la main, mais je suppose que ce n'est pas
énormément plus lent qu'un 266. C'est long à se lancer, certes, mais
une fois lancé ça marche très bien.
C'est long à lancer parce que ce sont des applis lourdent. C'est là

dessus que j'ai poussé mon coup de gueule.
Une fois lancé, ça bouffe des ressources, c'est la dessus aussi que j'ai
poussé mon coup de gueule.
Et tout ça non pour des fonctionnalités de la mort qui tue, mais parce
qu'ils reposent sur un framework lui même lourdingue !
De toute façon, pour cette bécane, je lui ai trouvé un meilleur usage :
elle est transformée en serveur :)

Laisse moi deviner... Tu utilises Fedora Core 2 ou un bidule de ce genre?
Tiens je vais lancer OpenOffice pour voir, top chrono.
Non, j'utilise debian sarge. Que ce soit au boulot ou à la maison.

Environ 10 secondes entre le clic sur l'icône et l'affichage de la
fenêtre au complet sur mon fringuant PIII 550/256 Mo. Je ne l'ai pas
lancé de la journée, donc il n'était pas dans le swap. Ça me paraît
tout à fait supportable comme attente, si tu ne peux pas attendre 10
secondes de temps en temps je te plains :)
Non, ce n'est pas du tout supportable au sens que non, effectivement, je

peux (ou sais) patienter ces 10s, mais c'est trop long pour démarrer une
application de ce genre !
10s ! C'est horrible ! Et ça l'est d'autant à mes yeux les réactions du
genre "c'est raisonnable" ! C'est du n'importe quoi, j'ai l'impression
d'entendre les windowsiens ! A force de nous immerger de bousin, ça nous
parait normal, et le pire c'est que l'on se rend même pas compte de ce
que l'on dit ("c'est normal", à force de le répéter, on finit par le
croire). On n'arrive même plus à remettre en cause de pareil raisonnement !

Miguel

39 euros chacun. Pas monstrueux, quand même.

Apéritif, vin, entrée et plats à la carte, thé et café. C'est
pas spécialement bon marché mais c'est _excellent_, avec en prime
service agréable et cadre sympathique. Je recommande.

Le Caroubier
Spécialité Afrique du Nord. Couscous, Tagines, Pastilla
01 40 43 16 12

82 bd Lefebvre 75015
à 500m du métro "Porte de Vanves" (vers l'ouest)

--

Comment créer un fichier binaire sans source ? Installes-toi devant
gimp pendant une heure, je suis sûr que tu trouveras.
Tiens, effectivement, je n'avais pas pensé aux fichiers core ;-)

--DLFP

Non, ce n'est pas du tout supportable au sens que non, effectivement, je
peux (ou sais) patienter ces 10s, mais c'est trop long pour démarrer une
application de ce genre !
10s ! C'est horrible ! Et ça l'est d'autant à mes yeux les réactions du
genre "c'est raisonnable" ! C'est du n'importe quoi, j'ai l'impression
d'entendre les windowsiens ! A force de nous immerger de bousin, ça nous
parait normal, et le pire c'est que l'on se rend même pas compte de ce
que l'on dit ("c'est normal", à force de le répéter, on finit par le
croire). On n'arrive même plus à remettre en cause de pareil raisonnement !

Il y'a un caractere un peu paradoxal a la situation : alors que les
machines ont des procs/memoires/disques durs plus rapides et plus de
memoire. Que pendant les memes temps les algos progressent ...
On tombe sur une utilisation au final plus lourde dans la plupart des cas.
En gros, ce qui fait ramer, c'est pas specialement les applis qui sont
specialement plus compliquees (enfin, pas dans ces mesures), mais, a mon
avis, a la lourdeur et au nombre de couches qu'il faut atteindre dans
des toolkits pour afficher un bouton, une fenetre ....
Evidemment, d'un point de vue GL, c'est *joli*, puisqu'on fait de la
reutilisabilite, par contre en pratique, qu'est-ce que c'est lourd...
Apres, je parle meme pas des programmes supplementaires pour la
communication entre process dans les environnements comme gnome, ou le
service de fontes . Je ne parle pas d'ipc, mais de la communication pour
faire du copier/coller par exemple.

Apres, est-ce qu'un environnement de type gnome ou kde (pas teste) ne
peut etre que lourd en fonction des *facilites* qu'ils proposent, ou
est-ce que c'est juste mal pense ou/et programme comme un pied ?

Le Fri, 27 Aug 2004 10:35:46 +0200, Miguel Moquillon a écrit :

C'est long à lancer parce que ce sont des applis lourdent. C'est là
dessus que j'ai poussé mon coup de gueule.
Une fois lancé, ça bouffe des ressources, c'est la dessus aussi que j'ai
poussé mon coup de gueule.
Et tout ça non pour des fonctionnalités de la mort qui tue, mais parce
qu'ils reposent sur un framework lui même lourdingue !

Tu délires. Il y a des fonctionnalités sans commune mesure entre
OpenOffice et MS OFfice 4.2 : l'export PDF, la 3D... AbiWord se lance
presque instantanément, mais Abiword fait moins de trucs.
D'ailleurs sur un PC actuel OpenOffice se lance en 1 ou 2 secondes, faut
arrêter.
On pourra certainement améliorer la vitesse de lancement de Mozilla,
OpenOffice, Gnome ou KDE (d'ailleurs ils sont tous de plus en rapides à
se lancer à chaque version) mais on ne peut pas demander la lune non
plus. Si tu trouves qu'ils sont lourds utilise windowmaker, dillo et
Abiword et arrête de geindre, il y en a pour tous les goûts.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando

Evidemment, d'un point de vue GL, c'est *joli*, puisqu'on fait
de la reutilisabilite, par contre en pratique, qu'est-ce que
c'est lourd...

Je trouve normal qu'une partie des gains de puissance du
matériel soit utilisée pour faire la même chose qu'avant
mais de manière plus facile pour les programmeurs. L'idée
est qu'au bout du compte, cela bénéficie _aussi_ aux
utilisateurs, puisque cela permet (en théorie) aux programmeurs
de programmer plus facilement, plus vite, plus sûrement et
de manière plus portable.

Une autre partie des gains de puissance est utilisée pour
ajouter de nouvelles fonctionnalités. En gros les application
deviennent plus complexes dans ce qu'elles font. Les couches
supplémentaires sont alors parfois tout simplement _nécessaires_
pour cette complexité.

On peut imaginer d'utiliser des couches abstraites, facilitant
la conception et la programmation, mais qui sont finalement
"implémentée" d'une manière presque transparente pour les performances.
C'est en gros un des principes de départ de C++. C'est aussi l'idée
derrière les compilations en code natif des langages de machines
virtuelles.

Je crois que les couches et composants sont inévitables et ne feront
que prospérer. Tu ne peux pas les rejeter sur la seule raison des
impacts éventuellement négatifs sur les performances. Par contre, tu
peux penser qu'améliorer _l'implémentation_ demande beaucoup
d'expérience et de travail...

--
I just learned today that at least one dog has three legs.
I wouldn't be surprised if a bunch of dogs have three legs.
Obviously most dogs have three legs.
--Graham Rounce

Manuel Leclerc wrote:

Evidemment, d'un point de vue GL, c'est *joli*, puisqu'on fait
de la reutilisabilite, par contre en pratique, qu'est-ce que
c'est lourd...

Je trouve normal qu'une partie des gains de puissance du
matériel soit utilisée pour faire la même chose qu'avant
mais de manière plus facile pour les programmeurs. L'idée
est qu'au bout du compte, cela bénéficie _aussi_ aux
utilisateurs, puisque cela permet (en théorie) aux programmeurs
de programmer plus facilement, plus vite, plus sûrement et
de manière plus portable.

Une autre partie des gains de puissance est utilisée pour
ajouter de nouvelles fonctionnalités. En gros les application
deviennent plus complexes dans ce qu'elles font. Les couches
supplémentaires sont alors parfois tout simplement _nécessaires_
pour cette complexité.

On peut imaginer d'utiliser des couches abstraites, facilitant
la conception et la programmation, mais qui sont finalement
"implémentée" d'une manière presque transparente pour les performances.
C'est en gros un des principes de départ de C++. C'est aussi l'idée
derrière les compilations en code natif des langages de machines
virtuelles.

Je crois que les couches et composants sont inévitables et ne feront
que prospérer. Tu ne peux pas les rejeter sur la seule raison des
impacts éventuellement négatifs sur les performances. Par contre, tu
peux penser qu'améliorer _l'implémentation_ demande beaucoup
d'expérience et de travail...

Je suis assez d'accord, seulement, la structure en couche et les
quelques fonctionnalites ajoutees ne justifient pas, a mon avis, que des
applis apres reecriture prennent tant de ressource que sur des procs
recents, se soit plus lourd qu'avec des versions plus anciennes sur des
vieilles machines. Je ne parle pas de la memoire. Il est clair qu'on
peut pas passer outre, notamment, a cause de l'utilisation omnipresente
d'images/icones/...

[topo sur les polices, toussa]

Merci d'avoir pris le temps de rédiger ce post.

Ceci dit.

Quand j'affiche en mode page dans un traitement de texte se
prétendant wysiwyg, il m'importe peu que la page fasse
réellement 21 cm de large à l'écran. Quand j'utilise une
fonte 12 points, je suis peut être très intéressé par le
fait qu'elle fera effectivement 12 points sur le papier, mais
sa taille en pouces sur l'écran n'est pas le sujet. Un même
écran peut être utilisé en 800 x 600 ou en 1024 x 768. On
pourrait imaginer un système qui affiche toujours (quelque
soit la résolution en cours) les applications de la même manière,
à savoir la manière qui fait que les pouces "théoriques" sont
bien rendus exactement (une règle posé sur l'écran le confirmant).
Dans un tel système, les pixels supplémentaires des hautes
résolutions ne seraient alors utilisés _que_ pour affiner/préciser
le dessin des caractères.

Je ne sais pas si un tel système existe. J'ai toujours vu des
systèmes dans lesquels le passage à une résolution élevée produisait
des fenêtres et des caractères plus petits, toutes choses étant
égales par ailleurs.

Autrement dit, je crois que la valeur "pixel par pouce" d'un système
est une valeur arbitraire, effectivement équivalente à ce que tu
appelles le facteur de zoom, mais uniquement pour les polices.
Utiliser ce paramètre en tant que facteur de zoom "général" demanderait
à ce que l'intégralité du système de dessin/fenêtrage se programme
en utilisant une autre unité que le pixel. Sous Windows, c'est
partiellement la cas pour les boites de dialogue, mais cela reste
limité.

A propos de CSS, j'étais justement tombé sur ça en googlant hier :
http://www.macromedia.com/fr/devnet/mx/articles/css_mmsite/css_mmsite.html

Mais ça date peut être un peu...

--
And so does windows. That doesn't make it good.
--Linus Torvalds

"Manuel Leclerc" , dans le message <412f0e3c@neottia.net>, a écrit :

Quand j'affiche en mode page dans un traitement de texte se
prétendant wysiwyg, il m'importe peu que la page fasse
réellement 21 cm de large à l'écran.

En effet, en général ce n'est pas important. Mais parfois, ça l'est (par
exemple pour comparer avec un document déjà imprimé), et il est bien
pratique de ne pas avoir besoin, à ce moment, de tâtonner pour obtenir
ce résultat.

Un même
écran peut être utilisé en 800 x 600 ou en 1024 x 768. On
pourrait imaginer un système qui affiche toujours (quelque
soit la résolution en cours) les applications de la même manière,
à savoir la manière qui fait que les pouces "théoriques" sont
bien rendus exactement (une règle posé sur l'écran le confirmant).
Dans un tel système, les pixels supplémentaires des hautes
résolutions ne seraient alors utilisés _que_ pour affiner/préciser
le dessin des caractères.

Oui, c'est bien de ça que je parle.

Je ne sais pas si un tel système existe.

X11 fonctionne comme ça, à condition que les applications se donnent la
peine d'utiliser les interfaces convenables, ce qui commence à être le
cas de manière généralisée. C'est en particulie vrai avec Gtk+ 2, donc
avec tout Gnome ; je soupçonne que c'est valable pour toutes les
applications qui utilisent Fontconfig, donc KDE aussi.

Exemple : mon écran actuel est en 800×600 et en 248×184 mm. J'ai demandé
à Gtk+ « font_name = "Helvetica 9" ». Un zoom m'indique que les lettres
font 10 pixels de corps, soit 3,06 mm, 8,7 points (11 pixels donneraient
9,6 points, c'est donc bien la meilleure approximation).

Maintenant, je change de résolution, et je ne fais rien d'autre (pas de
changement de config) : je passe en 640×480 (avec xrandr, Ctrl-Alt-+/-
ne fait pas un vrai changement de résolution). Nouveau zoom : les
lettres font maintenant 9 pixels de corps, soit 9,8 points.

Un petit détail pour être parfaitement honnête : les applications déjà
lancées lors du changement de résolution ne le voient pas, seules les
applications lancées après le changement de résolution sont influencées.
Mais c'est tout à fait satifsaisant à mon sens.

Autrement dit, je crois que la valeur "pixel par pouce" d'un système
est une valeur arbitraire, effectivement équivalente à ce que tu
appelles le facteur de zoom, mais uniquement pour les polices.

As-tu essayé de régler la définition conformément à la réalité de ton
écran (82 DPI, donc, d'après les valeurs que tu as données), et de
regarder ce que ça donne, par exemple au niveau de la règle de word ?

A propos de CSS, j'étais justement tombé sur ça en googlant hier :
http://www.macromedia.com/fr/devnet/mx/articles/css_mmsite/css_mmsite.html

C'est impressionnant : ces types comprennent le problème, et y apportent
une réponse totalement mauvaise ! Et je ne parle pas du « font-size:
1em », qui en CSS, est absolument équivalent à pisser dans un violon.