comparaison des cadres de dessin de graphes java open source (JUNG et Prefuse) pour le dessin de la topologie du réseau.

Question

Parmi les cadres de dessin de graphes Java open source, lequel utiliser pour un diagramme de réseau répondant aux exigences suivantes ? Le graphe comptera moins de 1000 nœuds.

1) a des bords parallèles
2) les arêtes dirigées et non dirigées dans un même graphe
3) les nœuds représentés par des images
4) interaction de l'utilisateur avec les nœuds et les arêtes
5) ajouter/supprimer dynamiquement des nœuds et des arêtes
6) étiquetage multiple sur les nœuds et les arêtes, différents niveaux d'étiquetage peuvent être activés ou désactivés par les utilisateurs. (comme le dessin en couches et l'activation ou la désactivation d'une couche).
7) différents algorithmes de mise en page pour afficher les topologies en étoile, en anneau ou en maillage.

J'ai évalué JUNG et Prefuse. Voici ce que j'ai trouvé pour chacune de mes exigences.

1) Prefuse ne peut pas afficher les bords parallèles alors que JUNG le supporte. Le code de Prefuse peut-il être manipulé pour afficher des bords parallèles ? Comme cela implique des changements de base au niveau des données, je pense que ce serait plus difficile que les habituels changements de rendu personnalisés.

2) Je n'ai pas trouvé de référence à un graphe combiné (bords dirigés et non dirigés) dans prefuse et JUNG. Quelqu'un sait-il le contraire ?

3) Cela semble facile avec Prefuse et JUNG.

4) Encore une fois, prefuse et JUNG offrent tous deux un support pour l'interaction avec l'utilisateur.

5) La préfuse et la JUNG la soutiennent toutes deux. Quelles sont les performances de chaque framework lors du redécoupage du graphique ? J'ai vu dans un autre post que prefuse ne fonctionne pas bien pour les mises à jour dynamiques ( Boîte à outils Prefuse : ajout dynamique de nœuds et d'arêtes )

6) Cela revient à modifier le graphique et à le redessiner. La question est donc la même que pour 5)

7) JUNG et prefuse ont tous deux des algorithmes de disposition multiples. Mais lorsque j'ai essayé d'afficher le même ensemble de données en utilisant FruchtermanReingoldLayout dans JUNG et Prefuse, j'ai obtenu des affichages différents. Quelle en est la raison ? D'une manière ou d'une autre, les algorithmes de mise en page dans Prefuse semblent afficher une meilleure mise en page que dans JUNG (le rendu est également meilleur, je pense) bien que la plupart des algorithmes de mise en page dans Prefuse soient basés sur l'implémentation de JUNG. Les mises en page de Prefuse telles que ForceDirectedLayout/FruchtermanReingoldLayout et CircleLayout correspondent directement aux topologies en étoile, en cercle et en mailles.

En dehors de ces exigences, prefuse a un bon support pour les expressions et le langage de requête mais il semble qu'il ne soit pas activement développé contrairement à JUNG. Lequel a une meilleure visualisation ? Avez-vous des suggestions sur celui qui conviendrait le mieux et sur la façon de surmonter ses inconvénients ?

Existe-t-il d'autres cadres que je pourrais utiliser ?

Answer 1

Je suis l'un des créateurs et mainteneurs de JUNG, alors gardez cela à l'esprit pour les réponses ci-dessous.

Tout d'abord, je dois dire que l'auteur de Prefuse est l'ami d'un ami (et oui, nous nous sommes rencontrés) et qu'il a fait un excellent travail. Je n'ai pas d'expérience avec Prefuse, mais j'ai vu quelques belles visualisations créées avec lui.

Voici les réponses à ces questions pour JUNG. Plusieurs d'entre elles ((1), (2), (4)sont démontrées en PluggableRendererDemo :

1. Supporté (vous aurez besoin du bon modèle de données, tous ne supportent pas les bords parallèles pour des raisons de performance)
2. Prise en charge (encore une fois, vous devez disposer du bon modèle de données)
3. Pris en charge (voir ImageShaperDemo )
4. Pris en charge (la plupart des démos)
5. Pris en charge (voir GraphEditorDemo )
6. Non pris en charge directement, bien que vous puissiez certainement modifier les étiquettes de manière dynamique et utiliser le HTML pour rendre des étiquettes complexes.
7. Les algorithmes de mise en page de JUNG sont plutôt destinés aux réseaux généraux (avec quelques exceptions pour les arbres, etc.). Cependant, vous pouvez certainement construire vos propres algorithmes de mise en page, et beaucoup l'ont fait.

J'espère que cela vous aidera.

Answer 2

Il y a quelques années (2007 ?), j'ai utilisé prefuse pour visualiser des enregistrements de données d'appels. J'ai considéré prefuse, jung, jgraph et quelques autres et j'ai choisi prefuse. Au début, il est un peu difficile de comprendre prefuse, mais une fois que je me suis familiarisé avec lui, il est vraiment facile (à étendre) et amusant à utiliser. Je suppose que l'on peut dire la même chose de JUNG mais je ne l'ai jamais essayé.

1) Dans prefuse, il est très facile d'ajouter votre propre moteur de rendu personnalisé pour dessiner des bords parallèles - vous pouvez sous-classer le moteur EdgeRenderer par défaut et surcharger la méthode render(). Il n'est pas nécessaire d'apporter des "changements de base au niveau des données". Tout cela se trouve dans la partie vue, si vous voulez le voir comme un élément MVC.

2) Ce n'est pas vraiment un problème. Il y a plus d'une façon de le faire : 1) Vous pouvez avoir deux moteurs de rendu - l'un pour dessiner les arêtes dirigées et l'autre pour dessiner les arêtes non dirigées et ils fonctionneront très bien, et grouperont les arêtes de manière appropriée. 2) Mettez un drapeau (ajoutez une colonne booléenne dans le tuple de la table d'accompagnement en langage prefuse) pour indiquer si l'arête est dirigée et sautez la partie du dessin de la flèche en conséquence dans le EdgeRender en fonction de ce drapeau.

3) C'est très facile

4) idem

5) La dernière version de prefuse est "prefuse beta release 2007.10.21". J'ai utilisé la version précédente, qui présentait un problème de concurrence lors de l'ajout ou de la suppression de nœuds de manière dynamique - il manquait quelques mots-clés synchronisés, je suppose. J'ai résolu ce problème en m'assurant d'arrêter toutes les animations et actions (couleur, taille, disposition) lors de l'ajout ou de la suppression de nœuds - n'oubliez pas non plus de mettre à jour vos index lucene (si vous utilisez son moteur de recherche lucene intégré). La dernière version est censée résoudre ce problème de course mais je n'ai jamais eu l'occasion de l'essayer.

6) Puisque vous avez mentionné "l'étiquetage multiple", je pense que ce n'est pas une question de "modifier le graphique et de le redessiner" - il s'agit simplement de personnaliser vos restituteurs d'étiquettes/de bords pour ne dessiner que les étiquettes pertinentes, donc ce n'est pas vraiment un gros problème. De plus, je ne pense pas que cela soit lié au point 5.

7) Je ne suis pas surpris que le rendu du FruchtermanReingoldLayout par prefuse et JUNG soit différent - il y a quelques facteurs qui peuvent affecter ceci, l'un d'entre eux étant le nœud de départ où chaque implémentation commence le calcul, donc je ne m'inquiéterais pas trop de ce problème. Il est assez facile d'essayer les différents algorithmes d'agencement de graphe intégrés dans prefuse, vous pouvez donc aller de l'avant et vérifier lequel est le plus proche de ce que vous aimeriez avoir. Essayez RadialLayout et BalloonTreeLayout pour la disposition en étoile. ForceDirectedLayout nécessite un certain nombre d'itérations pour que le placement des nœuds soit "stable". Notez que ces itérations ne sont pas nécessaires pour être affichées, vous pouvez donc l'exécuter en arrière-plan et rendre le résultat final.

Je n'ai pas utilisé JUNG et je ne peux donc pas faire de commentaires à son sujet.

Sur la base de mon expérience avec prefuse, je le recommande vivement en raison de sa conception très bien pensée (IMHO) et de la séparation des responsabilités entre les composants. Jeffrey Heer (auteur de prefuse) a vraiment fait un bon travail.

Les choses auxquelles il faut faire attention si vous utilisez de la préfuse (ce sont les deux "pouces douloureux" dont je me souviens très bien lorsque je travaillais avec de la préfuse) :

1) Il y a un bogue où, lors d'un zoom arrière, les étiquettes des nœuds ne sont pas réduites de manière appropriée, de sorte qu'elles débordent de la boîte de délimitation du nœud, ce qui laisse des artefacts de dessin de police lorsque le nœud se déplace, car le moteur de rendu n'efface et ne redessine que les éléments situés dans la boîte de délimitation du nœud. IIRC ceci est causé par un bug dans la métrique des polices AWT elle-même. La solution consiste à laisser une marge suffisante entre l'étiquette et la boîte de délimitation du nœud.

2) Lorsque vous étendez les mises en page intégrées, vous pouvez rencontrer un ou deux problèmes de "scoping" où un membre de la superclasse auquel vous souhaitez avoir accès se voit attribuer l'attribut private au lieu de protected. La solution consiste alors à modifier la bibliothèque elle-même ou à créer une nouvelle classe sans en hériter (ce qui peut être un peu pénible !). Je suppose que vous pouvez dire la même chose pour d'autres bibliothèques Java. Tout le monde n'a pas le bénéfice du recul, non ? :)

Puisque vous avez posé cette question il y a environ un mois (au moment où j'écris ces lignes), j'aimerais savoir quelle a été votre décision et comment cela s'est passé pour vous si vous avez procédé à la mise en œuvre.

Answer 3

Je sais que vous avez spécifié jung et prefuse mais... J'ai eu une bonne expérience avec TomSawyer et yFiles. La liste d'exigences que vous avez proposée est très basique pour ces deux-là - et ils supportent beaucoup plus.

Ran.

Answer 4

Je suggère d'évaluer JGraph aussi.