Force-Directed Edge Bundling
Posted: 22 Mar 2010 09:44
This is the thread for asking more details about the Force-Directed Edge Bundling proposal.
Please post new questions on facebook group too (https://www.facebook.com/groups/gephi)
https://forum-gephi.org/
I think FDEB fits to the preview module because it's something you want to do for increasing the map readability and design after all and is not suitable for real-time calculation. The thing is that our 3d rendering engine only draws straight lines. Supporting bezier curves is completely killing performances, I made the test. That's why we keep curved lines for the preview module. Without the ability to draw the FDEB results in real-time, I think the proposal don't fit to the layout module.Yestin wrote:The goal of the proposal is adding FDEB to gephi. You said in the description of the proposal that it should be added in the preview module. Have you think about adding FDEB to the layout module? Or you think this is not reasonable? I looked through FDEB paper you supplied in general. In my point of view, FDEB is a graph rendering method or a layout method. Using edge bundling can reduce clutter of large graph. So addding it to the layout module is much properer, isn't it?
The preview module currently has a quite static architecture. It will need refactoring for adding some algorithms (FDEB) that can integrates the results in the model. The idea of Preview architecture is to be on top of all outputs (Processing, SVG, PDF). In other words Preview API has to be modified to support curves that FDEB will generate.Yestin wrote:You also said one of the task of the proposal is to refactor preview module. Should my application on the project contain the detail idea of how to refactor this?
Right, a new edge type will appear.Yestin wrote:I downloaded the source code of this project, and looked through the preview module in general. If we add FDEB in preview module, we may rewrite or implement edge related class first to fit the segmentation of this algorithm. Because of limitation of time, I have a little trouble in covering all the codes and architecture of the project. Do you have any introduction or suggestion?
Question 1 @Jeremy: Can you explain more as to why the supervisor system is not up to par? I'm looking at the code, but it would be very helpful if you could hone in on some problems.Note that I'm not very happy with the supervisor system. If needed, feel free to refactor it, or to implement its behavior in another way.
In retrospect, I have some doubts about implementing a caching system using the observer design pattern, especially when the observers are the thousand edges and nodes of a preview graph which is recreated relatively frequently. This could easily lead to memory leaks if one makes some changes and forgets to unsubscribe the old preview graph elements from their related supervisors. I think there could be better ideas in the literature, or even around the web.cklee wrote: Question 1 @Jeremy: Can you explain more as to why the supervisor system is not up to par? I'm looking at the code, but it would be very helpful if you could hone in on some problems.