Discussion :

[_skip]

Bonjour,

J'aimerai juste demander si certaines personnes ont constaté des lenteurs étranges sous linux avec SWT? Je m'explique, j'ai développé une petite application d'un écran destinée à tourner sur un petit Atom 1.6.

Sur cet écran, un champ texte et un grand scrolledComposite. Au fur et à mesure que des caractères sont tapés dans le champ texte, une requête vers une base H2 est effectuée et les résultats apparaissent dans le composite sous forme de boutons cliquables.

Sur mon ordi de dev en linux, aucun souci, la réactivité est parfaite entre chaque frappe clavier, les boutons apparaissent rapidement. En revanche sur l'atom 1.6 toujours en linux-gnome, là ça traîne entre chaque frappe, on sent que c'est pas fluide (on sent passer facilement 150-200ms) entre chaque affichage et cela donne l'impression que ça rame.

J'ai tenté plein d'optimisations sans succès, puis finalement j'ai testé mon application sur cette même machine en lançant Windows 7 (elle est en dual boot). Là surprise, c'était tout à fait fluide! J'ai profilé chaque étape de mon code, ce ne sont ni la création des boutons, ni la requête DB qui sont lentes (50ms max pour les 2 ensembles), on dirait que le gros du temps est consommé après la fin de l'exécution de mon listener! Au moment du réaffichage peut être?

Le pire encore, c'est que j'ai conçu cette même application sous Swing, même base de donnée, même principe et elle est parfaitement fluide. Pourquoi SWT est à la traîne? Est-ce que c'est la création dynamique de composants qui, contrairement à swing, demande des ressources natives OS?

J'ai cherché dans tous les sens, j'ai pensé aux drivers CG, au direct rendering de ma carte graphique mais tout ceci fonctionne et est activé selon l'utilitaire du package mesa-utils. J'ai essayé de passer mon bureau sous KDE et respectivement XFCE, pas d'amélioration. Changer openJDK pour hotspot, nada là aussi.

C'est un peu le comble, ayant choisi SWT parce que de réputation il offrait des performances nettement supérieures à Swing... Ben j'ai l'impression d'avoir un beau contre-exemple. Il y a des discussions trollesques Swing vs SWT plein le net mais en général, les performances de SWT sont admises comme meilleures (même si bcps disent que eclipse, basé sur swt, est plus fluide sous windows que sous linux). J'ai tout de même trouvé une discussion ou deux qui prétendaient que l'implémentation SWT pour gnome était pas excellente et que les gains de SWT par rapport à Swing étaient bien plus évidents sous windows.

Bref, sans partir dans le troll, j'aimerai bien savoir si certains d'entre vous ont eu l'occasion de remarquer des différences dans un sens ou l'autre.

[sinok]

La première chose serait d'utiliser un profiler (comme VisualVM fourni avec les JDK récents) pour voir où est réellement perdu le temps.

C'est un peu le comble, ayant choisi SWT parce que de réputation il offrait des performances nettement supérieures à Swing... Ben j'ai l'impression d'avoir un beau contre-exemple. Il y a des discussions trollesques Swing vs SWT plein le net mais en général, les performances de SWT sont admises comme meilleures (même si bcps disent que eclipse, basé sur swt, est plus fluide sous windows que sous linux). J'ai tout de même trouvé une discussion ou deux qui prétendaient que l'implémentation SWT pour gnome était pas excellente et que les gains de SWT par rapport à Swing étaient bien plus évidents sous windows.

Ca c'était il y a quelques années, depuis les optis réalisés pour Swing lors des cycles de dev java 5/java 6 ont largement réduit la marge de manoeuvre des trolls.

Et il est probable que les surcouches SWT de GTK ne doivent pas être des plus brillantes, enfin historiquement SWT était plutôt rapide sous windows, mais se trainait pas mal dès qu'utilisée sous des OS basé sur des serveurs X... Les gars ayant codé l'implémentation GTK ayant pu être un peu pas propres ou que ne sais-je encore... Puis en général ils sont à la traine par rapport aux changements survenant dans GTK (par exemple le bug ou l'intégralité des boutons des dialogues d'eclipse en fonctionnaient pas...)

A l'heure actuelle, le seul intérêt pour choisir SWT est de profiter de la plateforme RCP. Sinon autant prendre de Swing qui, malgré son age vénérable, propose une pholosophie de codage un tant soit peu plus moderne qu'SWT (qui lui ressemble à du vieil MFC toutpourri)...

Mais bon, sur de versions modernes de java, la différence est minime, sachant que de tout façon une partie des Widgets SWT sont codés en software vu que ne possédant pas d'équivalents natif.

[Gueritarish]

Pour ce qui est des performances, pas mieux que Sinok (qui explique bien les choses ), pour être sur, il te faut utiliser un profiler.

Sinon, sans vouloir troller de façon intempestive, juste une remarque qui m'a titillé:

Sinon autant prendre de Swing qui, malgré son age vénérable, propose une pholosophie de codage un tant soit peu plus moderne qu'SWT (qui lui ressemble à du vieil MFC toutpourri)...

Alors, Sinok, il faut comparer ce qui est comparable
Tu ne peux pas comparer Swing et SWT. A la rigueur, on peut comparer AWT et SWT. Swing étant une surcouche d'AWT, tu peux éventuellement comparer Swing et JFace. Et pour le coup, JFace a une philosophie de codage semblable à celle de Swing

Voilà, pour la petite parenthèse.
Gueritarish

[sinok]

Alors, Sinok, il faut comparer ce qui est comparable
Tu ne peux pas comparer Swing et SWT. A la rigueur, on peut comparer AWT et SWT. Swing étant une surcouche d'AWT, tu peux éventuellement comparer Swing et JFace. Et pour le coup, JFace a une philosophie de codage semblable à celle de Swing

Voilà, pour la petite parenthèse.
Gueritarish

Et encore, Swing ne s'appuie que sur trois composants AWT: Windows, Dialog et Frame. Le reste des emprunts à AWT étant les Layouts et l'EDT et Java2D... Donc pas vraiment une surcouche au final, plutôt un toolkit reposant alternatif sur quelques éléments de base. Il est extrêmement rare de devoir aller fouiller dans AWT si l'on fait du Swing.
Alors que JFace est une vraie surcouche qui donne accès aux composants SWT utilisés lors de l'implémentation.

[Gueritarish]

Il est extrêmement rare de devoir aller fouiller dans AWT si l'on fait du Swing. Alors que JFace est une vraie surcouche qui donne accès aux composants SWT utilisés lors de l'implémentation.

Tout à fait, mais il n'en reste pas moins vrai que JFace, à la manière de Swing, reste plus "haut niveau" dans sa philosophie.
Après, j'apprendrais à faire de vrai recherche quand je veux parler de quelque chose (je parle de Swing dont je ne maîtrise que les bases du basique ).

[_skip]

Bonjour et merci pour les interventions.
En pré-créant tous mes boutons et en ne jouant plus qu'avec les attributs setVisible(), j'arrive à améliorer nettement les performances de mon appli SWT ce qui signifie qu'effectivement, la création dynamique de widget est assez significativement coûteuse en SWT.

En revanche, le défaut de cette approche est que l'ascenseur de mon scrolledComposite reste dimensionné pour afficher 60 éléments alors qu'il peut n'y en avoir que 10 affichés.
La je dois dire que swing est plus prévisible sur ce terrain puisque SWT n'a pas de notion de min et max pour la taille d'un widget mais juste un preferred. Ca rend d'ailleurs le MigLayout relativement inutilisable.

En fait, si seulement en Swing je pouvais avoir le printDialog natif du système sous linux plutôt que le tout pourri à la sauce java qui est incapable de détecter les formats papiers supportés par l'imprimante correctement. J'aurai plus besoin de SWT.