Discussion :

[kisitomomotene]

Salut à tous

Si mes connaissances sont exactes AWT utilise les fonctions système pour le rendering de ces composants, et il en est de même pour SWT.
D'autre part je crois que AWT est plus lent que swing et celui est plus lent que SWT.
Donc AWT est plus lent que SWT, et apparemment les deux utilient la même principe de fonctionnement...
Quelqu'un peut il mieux m'éclaircir?
Merci

[sinok]

Comment dire...

AWT date (il était déja présent aux débuts de java ce qui commence à remonter...)
Et depuis l'apparition de swing, on va dire que l'intérêt qui lui est porté est moindre...

[Gfx]

AWT n'est pas plus lent que Swing et Swing n'est pas plus lent que SWT. J'aimerais bien savoir d'où tu tiens tes informations...

[kisitomomotene]

AWT n'est pas plus lent que Swing et Swing n'est pas plus lent que SWT. J'aimerais bien savoir d'où tu tiens tes informations...

je croyais que les termes "poid lourd" pour qualifier AWT et "poid léger" pour swing étaient liés aux performances de l'une et l'autre technologie ( à moins que j'interprete mal les termes anglais heavyweight et lightweight )

quand à swt je croyais que le faq suivant en disant que swt consomme moins de mémoire que swing avait comme conséquence que swt est plus performant que swing.

[lunatix]

tu remarqueras que dans la FAQ, ca ne parle pas de performances (j'ai redigé cette partie de la faq). et pour cause, les deux api ont des performances equivalentes.

[Gfx]

Les termes heavyweight et lightweight n'ont aucun rapport avec les performances. Cela signifie simplement que les composants AWT reposent sur les composants du système, et pas ceux de Swing (enfin presque).

[kisitomomotene]

Les termes heavyweight et lightweight n'ont aucun rapport avec les performances. Cela signifie simplement que les composants AWT reposent sur les composants du système, et pas ceux de Swing (enfin presque).

Regarde à travers ce lien il y est notamment écrit:"Some of the benefits of using Swing components are:

More efficient use of resources.."

je crois que une meilleur utilisation des ressources aura necesairement des impacts sur les performances, en d'autre terme un des objectifs (le principal?) d'une meilleur gestion des ressources est l'amélioration des performances, on sait qu'on doit améliorer la gestion des ressources d'un programme à partir des indicateurs de performance.
D'autre part pourquoi d'après toi avoir prcecisement choisi le terme "poid lourd" pour désigner un composant qui repose sur du système? pourquoi on n'a pas choisi l'inverse "poid léger" plutôt? ou bien même trouver d'autre qualificatifs pour comparer swing et AWT?

[kisitomomotene]

tu remarqueras que dans la FAQ, ca ne parle pas de performances (j'ai redigé cette partie de la faq). et pour cause, les deux api ont des performances equivalentes.

Oui mais quand vous dites que swt consomme moins de mémoire sans contrepartie explicitement citée quelle est la conséquence par rapport à un composant qui consomme plus de memoire ( swing)? il n'est nulle part dit que swt consomme plus de temps processeur ou autre.. qui pourrait contre balancer son efficacité en gestion de la mémoire.
Je crois que si on veut rapidement faire comprendre à un profane qu'un logiciel A consomme moins de memoire qu'un logiciel B, c'est de lui dire que A sera plus performant que B, sinon je ne vois pas l'interêt de bien gérer une memoire..

[Gfx]

kisitomomotene : Bon, eh bien voilà la réponse donnée par une des personnes qui a concu écrit Swing...

19:58
Romain Guy
why are AWT components called heayweight
19:58
» and Swing ones lightweight?
19:59
Jeff Dinkins
AWT components were originally all native components, a native widget was instantiated for each object
20:00
» with swing there's only one native component (the window)
20:00
» that's basically it
Romain Guy
ok that's what I thought
20:01
» There is this guy on a forum
20:01
» that thinks that because of those names Swing is necessarily faster and ligher in memory than AWT
20:01
» lighter
20:02
Jeff Dinkins
not necessarily. Back in the old days, there were other concerns as well, such as on windows there was some kind of limitation as to how many native widgets you could instantiate
» I don't remember the exact number, but I doubt that's an issue any more
» and of course, the biggest issue was that with native widgets we can't intercept drawing and/or draw on top of them
» I once had a java bug where an app was throwing up hundreds of windows, and eventually you'd get the blue screen of death -- of course we were running into that native windows limit

Pour le moment tu t'es contenté de donner quelques affirmations à partir de tes interprétations très personnelles de deux mots.

[kisitomomotene]

Lorsque j'analyse moi même le comportement des composants Swings et AWT (sans me référer aux littératures). Une fenêtre qui contient un composant avec AWT va charger en memoire leur "peer" respectif, donc il y aura deux chargement en mémoire. Le composant swing équivalent va charger un composant en memoire ( la fenêtre) et desinner ensuite le composant, donc swing va utiliser moins de memoire que AWT, mais on ne peut à priori pas comparer les resources utilisées pour desiner le composant swing sur son container, et les resources utilisées par le code natif pour afficher le second composant. En conclusion les performances de l'une par rapport à l'autre vont dépendre de plusieurs facteurs ( le code natif, la jvm etc..)

[Gfx]

Non seulement ça, mais les composants Swing peuvent utiliser plus de mémoire que les composants natifs, ne serait-ce que parce qu'ils offrent plus d'états, et donc de champs internes, parce qu'ils sont liés à des UI delegates, qu'ils manipulent des modèles au lieu de simples valeurs etc.