JUNG无法显示大图?

发布于 2024-08-23 16:26:23 字数 90 浏览 6 评论 0原文

我在一个项目中使用 JUNG,当我显示相对较大的图形(例如 1500 个节点)时,我的电脑将无法处理它(图形已渲染,但如果我想导航图形,系统会变得非常慢)。任何建议。

I am using JUNG for a project and when I am displaying relatively large graphs eg 1500 nodes, my pc would not be able to handle it (graphs are rendered but If I want to navigate the graph the system become very slow). Any Suggestions.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

扭转时空 2024-08-30 16:26:23

因此,JUNG 可视化现在有两件事并不总是能够很好地扩展:

  1. 迭代力导向布局
  2. 交互:确定悬停和单击事件引用了哪个节点或边缘(如果有)。

听起来您现在遇到的是后者。

根据您的要求,您有几个选择:

  • (a) 关闭鼠标事件,或至少关闭悬停事件
  • (b) 破解可视化系统,以便事件目标的查找不是 O(m+n)。

(b) 的简单解决方案基本上只是将查看区域划分为较小的块,并且仅将事件发送到与指针位于同一块中的元素。 (显然,块越小,需要的内存就越多。)

我们计划 (b)(以及草拟的设计)已经有一段时间了,但一直在做其他事情。任何想要帮助获得更永久解决方案的人,请与我联系。

So, there are two things that JUNG visualization doesn't always scale very well right now:

  1. iterative force-directed layouts
  2. interaction: figuring out which node or edge (if any) is being referenced for hover and click events.

It sounds like it's the latter that you're running into right now.

Depending on your requirements, you have a couple of options:

  • (a) turn off mouse events, or at least hover events
  • (b) hack the visualization system so that lookups of event targets aren't O(m+n).

Simple solutions for (b) basically just partition the viewing area into smallish chunks and only sends events to elements that are in the same chunk as the pointer. (Obviously, the smaller you make the chunks, the more memory is required.)

We've had plans to do (b) (and a design sketched out) for some time but have been working on other things. Anyone that wants to help with a more permanent solution, please contact me.

撩心不撩汉 2024-08-30 16:26:23

您启动虚拟机时使用了多少内存?假设您在 Windows 上工作,查看任务管理器,虚拟机是否达到分配内存的最大量并开始使用交换?

How much memory are you starting your VM with? Assuming your working on windows, looking at the Task Manager, does the VM hit the maximum amount of allocated memory and start using swap?

鹿港小镇 2024-08-30 16:26:23

问题可能在于顶点位置的计算。我发现相当容易计算的唯一布局是树布局,显然它并不适合所有数据集。

解决方案可能是编写您自己的自定义布局,其计算量比 FRLayout 少得多。

The problem probably lies with the calculation of your vertices' positions. The only layout that I've found fairly easy to calculate was the Tree Layout and obviously that's not suitable for all data sets.

The solution probably is to write your own custom layout with a lot less calculations than say an FRLayout.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文