Stuttering Layouts

[everbeek]

I recently added time stamp comparisons between graph changes and last layout refresh. It is now causing problems when triggering layouts such as the circle layout (and probably other non-force ones). I suspect that this is largely due to the use of transition() from D3 and easing, I believe.

To replicate, load a medium sized graph, and click to the circle layout while it is still having nodes added.

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&restURLPrefix=data.bioontology.org

[everbeek]

Sorted it out with some timing thresholds and reductions of transition time on refresh calls. This makes it so that it is smooth if the layout is occurring while the graph is growing (unless it grows for too long, then it suddenly snaps into place). It isn't the best solution, but a first approximation nonetheless.

Also, there is a threshold for whether the layout transition tracking is stale or not. If it is made stale, then retriggers via concept expansions, etc can get proper layouts.

[everbeek]

Check if we can detect transitions underway. If we can, perhaps this can help us determine whether to start a new one or not. It's silly that I didn't think of that right away.

[everbeek]

Can't yet find a way to detect if transitions are underway, but I have another inkling of an idea. Perhaps we could fire fresh transitions for new nodes, or small groupings thereof. These independent transitions could do the trick.

https://github.com/mbostock/d3/wiki/Transitions https://github.com/mbostock/d3/wiki/Transitions#each

Alternately...transitions are based on time, which I understand the convenience of, but ultimately I want behavior more like tick(), where we can move by a fixed pixel distance per step. This would allow us to arbitrarily change the position of a node, and have it change its path to get there. I am already using linear time transitions, and straight line animations are very fine for our purposes. Should I do something like create DOM mutation observers on a targetCoordinate property, register said node, and fire a global timer that executes tick() essentially? Or should I wrap all the non-force into modified tick() methods to do the same? Using the force layout system allows for freezing of nodes, etc...but it also cools at some point...

DOM Mutation observers could be used to watch node coordinates and update arcs based on those changes:

http://addyosmani.com/blog/mutation-observers/ https://github.com/Polymer/MutationObservers https://github.com/kapetan/jquery-observe http://weblog.west-wind.com/posts/2011/Feb/22/A-jQuery-Plugin-to-monitor-Html-Element-CSS-Changes

http://stackoverflow.com/questions/1882224/is-there-an-alternative-to-domattrmodified-that-will-work-in-webkit http://www.w3.org/TR/SVG/interact.html

Another niggling problem is that when changing views, the timer for the previous refresh is used, so quick view changes cause no animation to be used. I shall fix that when I have layouts behaving well with undo/redo (#392, #409).

I have some higher priority cases to work on. This is being deferred for at least a few days.

[everbeek]

Can no longer replicate. Arbitrary layout button clicks during load, particularly after force layout is triggered, don't seem to cause a disturbance in the force layout.