Incomplete Paths To Root

[everbeek]

Tracked down my old radial layout example for Elena, and found that the D3 expansions do not reconstruct all paths to root like the original Choosel ones did. This is disconcerting. I need to see if it's merely a bug or if I overlooked the possibility of multiple paths when I made this.

Choosel: http://bioportal-integration.bio-mixer.appspot.com/?mode=embed&embed_mode=paths_to_root&ontology_acronym=SNOMEDCT&full_concept_id=http://purl.bioontology.org/ontology/SNOMEDCT/54588003&restURLPrefix=data.bioontology.org

D3: http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=paths_to_root&ontology_acronym=SNOMEDCT&full_concept_id=http://purl.bioontology.org/ontology/SNOMEDCT/54588003

[everbeek]

There are some problems loading that are associated with my recent addition of a delay timer for mouse over tool tips. It was working very well before I committed, but when combined with changes to get the complete path, it seems to break. Also, I have noticed that edge addition gets slower and slower with the larger graph.

[everbeek]

Oh, it's a timer. The missedEventTimer is being called multiple times per node, once per second. Verify that the best design is to call every second, and also make it a singleton timer. I made a comment in there suggesting that I was wrong to make one per node.

I fixed some related timer problems, but the multiple timer issue is still present. It is actually like so: one node triggers one timer, the second node triggers two, the third triggers three, and so on. I fixed it so that they are only being triggered when I want them triggered (mouse over top of node or tool tip), whereas before it was a constant barrage of triggers. Sorting out a likely scoping problem for the timers. Oh, good, I had a comment predicting this problem. I needed to call the function on the D3 enter result rather than on selectAll. Solved. Sorting out some other niggling problems in the tipsy timers...

[everbeek]

I should have made a separate issue for the timer stuff..but alas...

Back to getting the full path to root parsed.

[everbeek]

Fixing the timer problem did not resolve the extreme latency of layouts (minutes). Pressing buttons doesn't trigger the layout for a very very long time, and the arcs are initialized at detached positions.

[everbeek]

My recent work on refreshing on edge addition was flawed because hovering over adds temporary edges (which shouldn't affect the layout). I added an argument to fix that, because it was blocking clear perception of the main layout problem.

I sorted that out too; I am experience build delay today, and probably have been for some time. I make changes, but they are not reflected when I refresh in the browser sometimes, and are others. I recently added a timer to prevent too many calls to the layout refresh function. I used a combination of timestamps comparing layout versus graph freshness, as well as a delay on a timer, to catch more refresh attempts. I had some errors in this that didn't crop up when I committed them. It seems to behave correctly now.

Unfortunately, it behaves oddly when running on the circle layout, for example. I am making a new issue to tweak this behavior, since it is desirable, but has created stuttering in some layouts. This is largely due to the use of transition() from D3 and easing, I believe. This issue is #424.

[everbeek]

Did a test merge of Elena's branch for #330, and that sorted most of this out. There is still a problem when the default layout is vertical tree, though it works when starting with force then changing to tree.

[everbeek]

Ok, when the initial graph load is not complete, the tree layout gets disrupted. I am verifying this by getting node counts and triggering the tree layout before and after the final node (and edge).

[everbeek]

Merged with Elena's tree improvements, and it is working well now.

There is a fundamental issue with growing a tree rather than having all nodes and arcs present before doing the tree layout. The problem is with the animation of the layout. I will try to convey it in words...the layout doesn't know which node will be the root, and the graph ends up changing its mind too much.

I am thinking about order of node addition, and maybe making it work with something like how tick() works, rather than using transitions.

[everbeek]

The reason that it loads this way is because the paths to root call does not provide the information necessary to create arcs right away.

I think that the best way to handle this would be to use the batch services Paul worked on specifically for us. I hadn't had time set up CORS to access this. Maybe now is the time.

I am trying a different parsing order to see if that cuts it. Setting up CORS will take quite a bit longer.

[everbeek]

Despite some ridiculous setbacks while implementing, I got this working without CORS.