Dreamweaver super lent...

[Loops]

Salut,

juste une petite question concernant DW... je le trouve assez lent sur ma becane. Certaines actions simples (recherche de fichier dans une liste par exemple, en tappant le debut du nom du fichier) entraine systématiquement la toupie et mette vraiment longtemps. Alors que sur Transmit, cette recherche simple se fait immédiatement.
Est ce normal ? y a t il une mise à jour à faire ?

Je suis sous Tiger et je pense avoir la puissance nécessaire pour le faire tourner rapidement.

Merci de votre aide

 

[Anabys]

J'ai exactement le même problème avec DW MX 2004, dès lors que je travaille sur un document assez long. Par exemple, sur un document qui fait à peu près 15 page A4, avec des images et du texte, si je sélectionne un paragraphe et que je lui applique un style, DW met 15 bonnes secondes à afficher les changements. Je pense que ça vient de la façon dont est construit DW, et peut être d'une mauvaise optimisation du code pour OSX. Dans tous les cas, je n'ai pas trouvé de solution vraiment convenable, à part lui libérer pas mal de RAM en fermant d'autres applications et lui laisser utiliser le proc à son gré en ne faisant rien d'autre en arrière plan qui puisse solliciter ce dernier.

 

[Loops]

merci, je suis "content" de pas être le seul, et que le probleme vienne bien de l'appli :s

Je trouve ça assez dingue car j'ai quand meme 1,5go de ram. Il devrait y avoir aucun soucis, surtout pour des utilisations vraiment basiques...
Est ce que ça le fait sur d'autres outils web (Golive par exemple) ?

 

[Anabys]

Oui ça le fait pour d'autres outils Web, dans différentes situations et peut être dans une moindre mesure. Toujours est-il que c'est compréhensible: le logiciel doit interpréter un code assez long pour l'afficher à l'écran en mode WYSIWYG, et le réinterpréter à chaque nouvelle modification. En mode code source, il n'y a pas ce genre de lenteurs.

 

[Loops]

je refuse de croire que le G5 n'a pas la puissance nécessaire pour cela. Mon TB 1,3ghz le fait tourner nickel et ne rame pas à trouver un nom de fichier par ordre alphabetique.

Après un rapide test de GoLive, il me semble pas ramer sur ces taches basiques.

Il serait bien que Macromedia / Adobe bosse dessus parce que je trouve ça quand même assez étonnant :/

 

[Leyry Hynemonth]

Oui ça le fait pour d'autres outils Web, dans différentes situations et peut être dans une moindre mesure. Toujours est-il que c'est compréhensible: le logiciel doit interpréter un code assez long pour l'afficher à l'écran en mode WYSIWYG, et le réinterpréter à chaque nouvelle modification. En mode code source, il n'y a pas ce genre de lenteurs.

Pas d'accord avec toi sur deux points : DMx ne fait pas trop dans le What You See Is What You Got (Ce que tu vois [à l'écran] est ce que tu as réellement [ex: quand tu l'imprime.] - Tiens ! Quelqu'un connais encore ce mot ??!!) : Le premier argument est porté sur les tableaux : Présence des bordure, même si elle sont définies à 0. Placement des photos, espace entre les lignes, etc. Ensuite, la façon d'interpréter le code source est bien différente de Internet Explorer (Pc ou Mac) ou de Firefox, qui lui même interprete le code d'une façon différante encore ! . Alors je suis d'accord sur le fait que DMx ne pouvait pas faire en sorte d'offrir un WYSIWYG commun à tous les navigateurs, mais ils auraient quand même puent choisir le plus léger, ou alors le plus connus (Relativement quand même... je sais bien.) Aussi, ayant connu la version PC, je eu LAAAAArgement le temps de voir que le rendu graphique du code source était ...][... => Minime !

Si on passe l'éponge sur le WYSIWIG, - on retombe donc sur le code source, Loops pourra certainement te dire que là aussi, c'est lent. (Même très lent ! - Pour mes pages en tout cas)

Je crois que l'hypothèse du mauvais portage OSx/Mac est à suivre. :zen: