This includes nearly a complete rewrite of d3.behavior.zoom, more closely
modeled after the Polymaps po.drag, po.touch and po.wheel classes. This makes
the code simpler and also fixes a bug when releasing one of two fingers.
I simplified the implementation to only support single-touch. I also opted not
to include touch support in the force-dynamic example (and other examples), just
because it complicates the examples too much. Touch is nice but I don't want it
to interfere with people learning the basics.
This merge also has an extra bonus fix: you can now have multiple force layouts
with dragging on the same page, and the drag behavior will do the direct the
event to the appropriate force layout.
This allows the Dorling/Demers cartograms to be slightly closer to the real
geography.
Also, fix the Dorling collision detection as self-collisions were previously
being detected. Thanks, Mike!
Lastly, I've removed the variable per-link distance as this is no longer needed.
There's now a new API for invoking the hierarchy layout (hierarchy.nodes) rather
than calling the layout function directly. Calling the new API enables inlining,
which is disabled by default for backwards-compatibility.
This way, we don't need symlinks (which don't work on Windows). This commit also
simplifies the structure of the flare.json file, so that we don't need to tricky
conversion of the JSON map—it can be read directly by the hierarchy layout.
You can now specify the domain of the quadtree upon construction, such that you
can add points to the quadtree dynamically later. The quadtree example now also
shows how to do a quick rectangular search using the quadtree.
There's already a tension parameter, and it seems reasonable to overload this
parameter (originally intended for cardinal splines) to also apply to bundle
splines. The new "bundle" interpolation is identical to "basis" interpolation;
the only difference is that the tension parameter is used to straighten the
basis spline.
I think this gives a better experience on big monitors. :-) I've also used
d3.timer to update the paths in case there is a backlog of mousemove events.
I'm not sure this is necessary but in testing on a fast machine sometimes it
processes two mousemove events and only draws the most recent one with this
change.
This reverts commit c5450fa62a.
It turns out this approximation is not that much faster than Math.{sin,cos}; I
think the perceived performance is more related to the responsiveness to the
"mousemove" event.