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.

[sinok]

Tu peux toujours essayer l'implémentation QT de SWT pour voir ce que ça donne http://code.google.com/a/eclipselabs...ki/DevEnvSetup

(bon ensuite moi et les dialogs Gnome on n'est pas vraiment très très copains en général, genre le file dialog, beurk...)

Autant ne pas utiliser le L&F système est passer par des bestioles comme Substance en Swing. (même s'il est vrai que les linuxien sont des intégristes de l'intégration des applis dans leur DE)...


Au pire tu utilises Swing pour la plupart des choses et tu prends juste SWT pour la partie impression

[_skip]

Tu peux toujours essayer l'implémentation QT de SWT pour voir ce que ça donne http://code.google.com/a/eclipselabs...ki/DevEnvSetup

http://groups.google.com/group/swtqt...0c05d36cf4a3cc
Tu vois ce topic? C'est le mien. Difficile de faire confiance à ce projet pour une application non triviale hélas... Même qtJambi ne m'inspire que peu confiance.

(bon ensuite moi et les dialogs Gnome on n'est pas vraiment très très copains en général, genre le file dialog, beurk...)

Justement le file dialog swing n'est pas connu loin à la ronde pour être hideux? Je sais pas j'ai pas essayé sérieusement mais j'ai lu pas mal de posts de gens mécontents dessus.

Autant ne pas utiliser le L&F système est passer par des bestioles comme Substance en Swing. (même s'il est vrai que les linuxien sont des intégristes de l'intégration des applis dans leur DE)...

Disons que dans mon cas, puisqu'il s'agit d'une application tactile cela m'arrange que ce soit pas standard car il y aura des boutons en couleurs et tout ça. Le truc c'est que tous les projets swingx sont morts en ce moment, site web à plat, problème de trust bizarre sur les certificats et personne ne trouve urgent de mettre tout ceci en ordre. C'est dommage car il y a des composants swingX intéressants.

Au pire tu utilises Swing pour la plupart des choses et tu prends juste SWT pour la partie impression

Mon application ne sera pas pure de toutes façons car j'ai besoin de certaines libs natives pour le port série. En revanche, devoir fournir le jar SWT juste pour un printdialog m'embête un peu.

J'ai hésité à faire un rapport de bug car l'API javax.print, en plus d'être non type-safe et d'une complexité ridicule, essaie à tout prix de mapper les tailles papiers existantes sur des format standards. Du coup mes étiquettes 17x54 deviennent du B8 alors que les dimensions du B8 ont juste rien à voir. Mais bon je serai mort de vieillesse avant que quelqu'un chez Oracle s'intéresse à mon cas.

[_skip]

Après investigation profonde, il s'agissait en fait des méthodes paintcomponent de mes boutons qui étaient particulièrement lentes. En fait les appels à gc.drawImage sont extrêmement coûteux sous GTK et il y en avait 9, le double buffering réduit le flicker mais n'améliore apparemment pas directement les performances.
J'ai résolu cela en créant un cache partagé entre tous les boutons contenant l'image toute pré-dessinée pouvant être peinte en un seul rectangle, seul le texte est redessiné à chaque fois mais ce n'est pas ça qui coûte cher. Sous windows, il semble que l'on profite automatiquement de certaines optimisations pour le dessin, ce qui rendait mon code tout à fait rapide.

[ZeRevo]

Tes tests ont été effectués avec quelle version de SWT ?

[_skip]

C'était la 3.6.
Mais je n'ai jamais été au bout, le projet a été abandonné par manque de moyens financiers du client.

[ZeRevo]

Dommage c'était un sujet intéressant.
Il aurait été possible de coder ton application avec GTK+ ou GtkMM pour voir si le problème venait de SWT.

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 philosophie de codage un tant soit peu plus moderne qu'SWT (qui lui ressemble à du vieil MFC toutpourri)...

La programmation avec Swing est intéressant mais le rendu n'est pas à la hauteur. Je suis entrain de développer une application multi-plateforme, j'avais commencé par la coder en Swing. J'étais très attaché au rendu et je n'ai jamais réussi à trouver un bon rendu des polices sous Linux. A côté du rendu des applications GTk+, mon application avait un très mauvais rendu. Pourtant j'utilisais les mêmes polices et j'avais activé toutes les options d'antialiasing disponibles. De plus le lookandfeel gtk n'est pas à la hauteur. Les entêtes des colonnes des tableaux n'est pas rendu correctement.

A contrario, avec SWT, je trouve le rendu très bon mais j'ai eu des problèmes avec les différents environnements, j'ai fais des tests sur chaque environnement pour corriger les bugs et problèmes d'affichages.

[_skip]

Dommage c'était un sujet intéressant.
Il aurait été possible de coder ton application avec GTK+ ou GtkMM pour voir si le problème venait de SWT.

La seule chose que je peux dire, c'est que d'une certaine manière le dessin de mes boutons en mode 9 images était bien plus coûteux dans sa version SWT que Swing sous linux. Sous windows aucun souci.
Mais une fois l'image finale mise en cache et réutilisée au fil des appels, c'était tout à fait fluide. C'était très difficile pour moi de m'apercevoir que c'était les méthodes de dessin qui massacraient les performances.

Toutefois, toute optimisation faite, mon application était plus rapide sous swing. Aussi étonnant que cela puisse paraître, j'arrive à programmer mes UI de façon très réactive. Je suis le premier à dire que Swing a un jour été merdique au niveau performance mais en se donnant un peu de mal, on peut faire de très bonnes choses.

La programmation avec Swing est intéressant mais le rendu n'est pas à la hauteur. Je suis entrain de développer une application multi-plateforme, j'avais commencé par la coder en Swing. J'étais très attaché au rendu et je n'ai jamais réussi à trouver un bon rendu des polices sous Linux. A côté du rendu des applications GTk+, mon application avait un très mauvais rendu. Pourtant j'utilisais les mêmes polices et j'avais activé toutes les options d'antialiasing disponibles.

Disons-le carrément : Les looks and feel livrés en standard sont des grosses merdes, même nimbus que tout le monde trouve formidable, perso il me dégoûte, pas sobre et peu lisible. Metal on n'en parle pas il est vieillot, moche et brouillon et Motif frôle le SM.

Mais cependant, il y a des trucs sympas sur le net :
http://www.jyloo.com/synthetica/screenshots/

Ou dans le gratuit, sobre et sympathique :
http://www.jtattoo.net/FastScreenShot.html
http://www.jtattoo.net/SmartScreenShot.html
http://www.jtattoo.net/AeroScreenShot.html

De plus le lookandfeel gtk n'est pas à la hauteur. Les entêtes des colonnes des tableaux n'est pas rendu correctement.

Les looks and feel natifs sont un peu de la plaisanterie, il suffit d'essayer une jtable sous XFCE, l'entête de colonne devient carrément un bouton.

A contrario, avec SWT, je trouve le rendu très bon mais j'ai eu des problèmes avec les différents environnements, j'ai fais des tests sur chaque environnement pour corriger les bugs et problèmes d'affichages.

Je pense que tu as résumé le truc : SWT a certes un look natif mais subit les limitations et les spécificités de la plateforme d'accueil, alors que Swing ne respecte pas le thème mais est passablement consistant.