FWD » Core Development » Conversion Tools

The current call-graph visualization becomes unusable for even small number of programs when complex frameworks (such as ADM/ADM2) are in use.

The biggest issue is the inefficient use of space. The need to avoid overlapping sibling nodes led to an approach where we created cells that acted like jails (contained nodes can't move past the cell boundaries). The problem here is that the cells must be big enough to contain the largest sibling nodes leaving most of the cells greatly oversized for the actual nodes being displayed. This makes the container node very large and wastes much of the interior space.

Even at the top (page) level, the jail cells approach leaves the result very difficult to use. This was also made more complicated because we had limited control over the distance between nodes and we needed to use the controls that did exist in a way that helped us avoid collisions. This made a bad situation worse.

I realize that we can also improve the visualization by enhancing the filtering, search and the expand/collapse capabilities. This is something we do want to explore as already documented in #3277.

But the core issue still exists. We either have to have a much more sophisticated approach to cells OR take a different approach.

I've recently found a potential framework that provides a different approach. It is called cola.js (see http://ialab.it.monash.edu/webcola/). What is really nice about this is that it implements the non-overlapping layout including alignment and grouping but with a significantly better use of the space. The resulting graph will be contained in a much smaller space, which should significantly improve the usability. What is critical, is that this works as a drop-in replacement for the D3 force directed layout, which is exactly what we need.

The down side is that they say it is really slow for larger graphs, so we may have to just be patient while it is loading.

I'd like to explore using this. It should be pretty straightforward to enable, but we will have to remove our current jail cell approach to make it work.

Greg, please take a look at 3701a rev 11303 - I don't think I can find something better than this.

Note that cola.js will not work with the 'Include All' option - the internal layout computation gets too expensive.

Do you want a code review? History entries and javadoc seem to be missing, so I can wait until you are ready.

I'm running ant report_server on Hotel GUI right now so I can test the results.

Greg Shah wrote:

Do you want a code review? History entries and javadoc seem to be missing, so I can wait until you are ready.

Not yet, I'll let you know. I need to finish the legend for the flowchart and code cleanup/javadocs.

The flowchart legend is in 11304.

This is very cool! I think it is a nice improvement for call graph and the flow chart support is in a good place for a v1.0.

Please make sure that the code reports are brought up by default when you start analytics. Otherwise, it is good to go. I'll do the code review when you are ready.

Code Review Task Branch3701a Revision 11305

The results are really good. FYI, considering the amount of change in callgraph.js and the amount of code in flowchart.js, I haven't done a comprehensive analysis of all code there.

1. Why are the private methods describeNode() and describeTooltip() in CallGraphApi being moved up into the public section? Were you planning to expose those as public?

2. The usage of arrow function syntax (=>) might be a problem. I think some browsers still don't support it. For example, at least at the beginning of the year IE v11 did not support it. Please check this. I think IE support is required.

Greg Shah wrote:

1. Why are the private methods describeNode() and describeTooltip() in CallGraphApi being moved up into the public section? Were you planning to expose those as public?

Since ever I thought that static methods should be before instance, regardless of access modifier... I'll move them back.

2. The usage of arrow function syntax (=>) might be a problem. I think some browsers still don't support it. For example, at least at the beginning of the year IE v11 did not support it. Please check this. I think IE support is required.

Argh, IE doesn't support lambda => notation. I'll fix this.

IE11 has problems rendering the links (which are polyline SVG elements). I think is related to stroke-width, but I'm not sure. Should I chase this down?

Constantin Asofiei wrote:

IE11 has problems rendering the links (which are polyline SVG elements). I think is related to stroke-width, but I'm not sure. Should I chase this down?

If it is quick, yes. If it gets too involved we can discuss.

Greg Shah wrote:

Constantin Asofiei wrote:

IE11 has problems rendering the links (which are polyline SVG elements). I think is related to stroke-width, but I'm not sure. Should I chase this down?

If it is quick, yes. If it gets too involved we can discuss.

If I change the stroke-width from 1 to 2, the polyline is rendered; back to 1, is rendered again. Something is preventing IE11 to render the polyline, I can't find anything online.

This is happening for the callgraph and flowchart, but if you open another flowchart and go back to the previous (which can be the callgraph or flowchart), then that will have the links rendered, now. Something is preventing IE to render the polyline elements when the SVG is first shown.

Just open a task for this and we won't work on it now. It seems likely this is just a browser bug and may get fixed in a later version.

Greg Shah wrote:

Just open a task for this and we won't work on it now. It seems likely this is just a browser bug and may get fixed in a later version.

Done, see #3742.

3701a rev 11306 fixes the IE11 compatibility issues (=> and other JS issues, plus a toolbox positioning issue).

I can merge it to trunk if you are OK with it.

What is left is changing FlowChart.dumpExpression to use the anti-parser (now it uses a crude/incomplete way of anti-parsing an AST).

I'm OK with the changes. Please merge to trunk. When 3696 is finished we'll handle the anti-parsing integration.

3701a was merged to trunk rev 11285 and archived.