Discussion :

[Malo]

bonjour,
je suis entrain de me lancer dans une GUI, qui consiste a visualiser un graphe (des noeuds et des arcs).

Le probleme est que je ne sais pas du tout comment faire ca proprement.

Pour l'instant je dessine tout sur le graphics d'un panel, en dessinant des ronds pour les noeuds et des droites pour les arcs.

J'ai deux problemes :

-J'aimerai pouvoir modifier le graph a travers l'interface graphique (ajouter un noeud ou un arc, deplacer un noeud). est ce que dessiner sur un panel combiner avec des listeners est la bonne methode ou y a t'il un moyen plus efficace?

-Je trouve que le rendu est moche, les couleurs et les contour des figures geometriques sont moches. J'ai vu des programmes en java ou les figures geometriques font moins "pixeliser" un peu comme dans flash, j'aimerai la meme chose.

Est ce que quelqu'uns sait comment faire?
merci beaucoup par avance

[bouye]

est ce que dessiner sur un panel combiner avec des listeners est la bonne methode

Oui mais je te conseilles de faire du double-buffering en dessinant dans une BufferedImage que tu afficheras dans ton panel vs. dessiner directement dans le paintComponent() du panel. Eventuellement apres si ton app est vraiment gourmande/lourde en ressources graphiques tu peux egalement voir du cote des VolatileImage et des BufferStrategy pour obtenir une acceleration materielle et une gestion de la pagination.

en java ou les figures geometriques font moins "pixeliser"

Il te faut modifier les options/indices de rendu de ton graphics au debut de ta methode dessin.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
g2d.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY);
g2d.setRenderingHint(RenderingHints.KEY_ANTIALISING, RenderingHints.VALUE_ANTIALIAS_ON);

voir les class java.awt.Graphics2D et java.awt.RenderingHints pour les differentes methodes, cles et valeurs.

[Malo]

ok. Donc je suis pas loin de la bonne methode, tant mieux! Je vais faire ce que tu me conseils a savoir faire du double buffering., d'ailleurs j'ai pas vraiment le choix si je veux avoir un meilleur rendu graphique. D'ailleurs sur ce points, j'ai testé et je te dis un grand grand merci, ca change tout! c'est tout beau maintenant.

[bouye]

De rien, n'oublie pas qu'il y a un autre indice de rendu pour controler separement l'antialias sur le texte (KEY_TEXT_ANTIALIASING).

[Gfx]

Ou mieux, tu ne fais rien et tu utilises la bibliothèque open source JGraph Je l'ai utilisée dans un projet et elle fait gagner beaucoup de temps. La documentation est très succinte mais en lisant des exemples tu ne devrais avoir aucun problème.

Quant au double buffering heu... si tu fais du Swing tu n'as pas à t'en préoccuper. La plupart des composants le gèrent par défaut.

[bouye]

Euh certes surtout que ca sera enfin correctement implémenté dans Java 6 si j'ai bien compris la liste de changements prévus pour Swing (pas taper gwan patwon pas taper).

Mais je préfère nettement dessiner à part du code de rendu du composant surtout quand on a pas mal de traitement graphiques. C'est bien plus rapide de décharger le rendu sur une simple image/bitmap . Image qu'on compose ensuite en un seul appel dans le code du paintComponent. Le traitement peut même être eventuellement dans une thread séparée (celon le besoin de l'app)

Ensuite réutiliser l'existant et savoir fouiller pour trouver des lib gratuites c'est bien mais des fois on a besoin de savoir faire des chosess soi-même non ? Ca donne une base de connaissance et d'expérience personnelle.

Hors sujet terminé, désolé patwon.

[Gfx]

Non le double buffering fonctionne très bien dans Java 5 et antérieur. C'est un autre double buffering qui est corrigé dans Java 6 ) Sinon je ne vais pas te contredire sur l'usage d'une BufferedImage, je le fais très souvent pour les démos Swing que j'écrit. Leur usage permet surtout d'éviter de refaire les opérations de dessin, donc de ne pas redessiner le composant à chaque appel de paintComponent(). J'avoue que chaque fois que je lis double-buffering en Java je repense à Java 1.1 dans lequel on faisait ça pour éviter le scintillement lors de l'affichage ^^ Et c'est ce double buffering en question qui est géré par Swing.

L'optimisation avec une BufferedImage est encore un cran au dessus et n'est pas pour moi du double buffering mais de la mise en cache (on pourrait discuter longtemps sur les différences mais pour moi les deux sont différents).

Ensuite réutiliser l'existant et savoir fouiller pour trouver des lib gratuites c'est bien mais des fois on a besoin de savoir faire des chosess soi-même non ? Ca donne une base de connaissance et d'expérience personnelle.

Certes mais pas au point de perdre un temps incroyable à refaire un système de graphe. La réutilisation cela s'apprend également.

[bouye]

Ok y me semble que la terminologie sur le site de Sun dans un des didacticiel n'était pas correcte alors. A moins que ce ne fut dans le bouquin d'Oreilly sur Java2D. Hum chais pu, trop loin tout ça (1999~2000) ; en tout ca il ne parlaient pas de triple-buffering pour cette méthode.

Pour le terme offscreen composition je l'ai souvent vu utilisé depuis l'apparition des BufferStrategy mais pas (trop) avant. Pourtant le principe est juste le même mais juste avec plus d'image et une gestion du pointeur de graphics actif automatique.

Merci pour ces rectifications en tout cas.

[Gfx]

Disons qu'il faut savoir où se trouvent les différentes optimisations. Il serait dommage par exemple d'appliquer à tout va la gestion du BufferStrategy ou de la BufferedImage alors qu'on pourrait s'en passer pour des cas simples ou des composants rarements affichés. Non seulement on gagne du temps mais surtout de la mémoire. Une BufferedImage en TYPE_INT_ARGB ça peut rapidement prendre pas mal de mémoire si on en met dans tous les composants. Swing se débrouille déjà assez bien pour manger la RAM

[archadius]

Je travaille actuellement avec des graphes et j'utilise l'API Prefuse. C'est un excellent outil ! Très accessible malgré le manque de documentation. Il y a plusieurs exemples d'implémentation complets et il existe par ailleurs un forum consacré à Prefuse, qui permet de trouver des solutions et de poser ses questions.

http://prefuse.sourceforge.net/