比较用于绘制网络拓扑的开源Java图形绘制框架（JUNG和Prefuse）

Question

哪些网络图使用以下开源Java图形绘制框架？该图将少于1000个节点。

1）具有平行边缘
2）单个图形内的有向和无向边缘
3）由图像表示的节点
4）用户与节点和边缘的交互
5）动态添加/删除节点和边缘
6）在节点和边缘上有多个标签，不同级别的用户可以关闭/打开标签。（例如绘制图层并关闭/在图层上）
7）不同的布局算法以显示星形，环形，网格拓扑

我评估了荣格和Prefuse。这是我为我的每个需求找到的。

1）在JUNG支持下，预熔无法显示平行边缘。可以操纵预填充代码以显示平行边吗？因为这涉及到基本数据级别的更改，所以我相信这将比通常的定制渲染更改更加困难。

2）我在预熔丝和JUNG中都没有找到对组合图（有向边和无向边）的任何引用。有人知道吗？

3）Prefuse和JUNG看起来都很容易

4）再次，prefuse和JUNG都为用户交互提供了支持。

5）预告片和荣格都支持。重画图形时每个框架的性能如何？我在另一篇文章中看到，预贴在动态更新方面效果不佳PrefuseToolkit：动态添加节点和边）

6）这归结为修改图形并重新绘制它。因此问题与5）相同

7）JUNG和prefuse都有多种布局算法。但是，当我尝试在JUNG和Prefuse中使用FruchtermanReingoldLayout显示相同的数据集时，会得到不同的显示。有什么主意吗？尽管Prefuse中的大多数布局算法都基于JUNG实现，但在某种程度上，Prefuse中的布局算法似乎比JUNG中显示更好的布局（我认为渲染效果也更好）。Prefuse布局（例如ForceDirectedLayout
/ FruchtermanReingoldLayout和CircleLayout）直接映射到星形，圆形，网格拓扑。

除了这些要求之外，prefuse还对表达式和查询语言提供了很好的支持，但是看起来它并没有像JUNG那样积极地开发。哪一个具有更好的可视化效果？有什么建议适合哪个人，以及如何克服这些缺点？

我可以使用其他框架吗？

Answer 1

几年前（2007年？），我使用预熔技术可视化呼叫数据记录。我考虑了预注，jung，jgraph和其他一些内容，然后选择了预注。刚开始时，将我的头缠在预告片上有点困难，但是一旦我熟悉了它，它真的很容易（扩展）并且使用起来很有趣。我想对JUNG可以说相同，但我从未尝试过。

1）预先添加用于绘制平行边缘的自定义渲染器非常容易-
您可以将默认EdgeRenderer子类化并覆盖render（）方法。无需“基本数据级别更改”。如果您想将其视为MVC素材，则这些都在视图部分中。

2）这根本不是问题。有多种方法可以做到这一点：1）您可以有两个渲染器-
一个用于绘制有向边缘的渲染器，一个用于绘制无向边缘的渲染器，它们将很好地工作，并适当地对边缘进行分组。2）放置一个标志（在预言中在后勤表元组中添加一个布尔列）以指示边缘是否有向，并根据该标志相应地在EdgeRender中跳过箭头绘制部分。

3）这很容易

4）同上

5）最后一个预发布版本是“预发布beta版本2007.10.21”。在此之前，我使用了一个，在动态添加或删除节点时，它可能具有竞争条件-
我猜想它缺少一些同步关键字。我通过确保在添加或删除节点时停止所有动画和动作（颜色，大小，布局）来解决该问题-
也不要忘记也更新lucene索引（如果您确实使用其内置的lucene搜索引擎）。最新的解决方案应该可以解决此比赛问题，但是我从来没有机会尝试一下。

6）既然您提到了“多个标签”，我认为这不是“修改图形并重绘”的问题-
只是自定义标签/边缘渲染器仅绘制相关标签的问题，因此这并不是一个大问题。而且我也不认为这与5相关。

7）我不惊讶于预混和JUNG的FruchtermanReingoldLayout呈现方式有所不同-
有一些因素可能会影响其中之一，即每个实现开始计算的起始节点，因此我不必担心这个问题。预先尝试不同的内置图形布局算法是很容易的，因此您可以继续进行检查，以找出最接近您想要的图形布局算法。查看RadialLayout和BalloonTreeLayout的星形布局。ForceDirectedLayout需要进行多次迭代才能使节点的放置“稳定”。请注意，不必显示这些迭代，因此您可以在后台运行它并呈现最终结果。

我没有用过JUNG，所以我无法对此发表过多评论。

根据我对预涂胶的经验，我极力推荐此方法，因为它经过精心设计（IMHO），并且组件之间的可回收性分开。杰弗里·海尔（Jeffrey
Heer）（预言作者）在这里确实做得很好。

如果您使用预熔，要注意的事情（这是我在使用预熔时生动地记得的两个“痛拇指”）：

1）有一个错误，即当缩小时，节点标签未适当缩小，从而溢出了节点的边界框，这会在节点移动时留下字体绘制工件，因为渲染器仅清除并重新绘制节点边界内的内容框。IIRC，这是由AWT字体指标本身的错误引起的。解决方法是在标签和节点边界框​​之间留出足够的边距。

2）扩展内置布局时，您可能会遇到一个或两个“范围问题”，其中您要访问的超类成员被赋予了private属性而不是protected属性，因此解决方案是修改库本身，或者创建一个不继承的新类（这可能会很痛苦！）。我猜您可以对其他一些Java库说同样的话。并非每个人都具有事后看来的好处吗？:)

由于您是大约一个月前（在撰写本文时）提出此问题的，所以我想知道您的决定是什么，如果您继续实施该计划，结果会如何。