- 06 Oct, 2012 1 commit
-
-
Mike Bostock authored
-
- 05 Oct, 2012 20 commits
-
-
Mike Bostock authored
We'll still use the major-versioned name file for d3js.org, but this is simpler.
-
-
Mike Bostock authored
-
Jason Davies authored
-
Mike Bostock authored
-
Mike Bostock authored
-
Mike Bostock authored
-
Mike Bostock authored
-
Mike Bostock authored
Remove d3.geo.albers origin.
-
Jason Davies authored
Also adds support for previously unsupported object types e.g. Points and LineStrings.
-
Mike Bostock authored
-
Mike Bostock authored
I never used these. They're fired!
-
Mike Bostock authored
Conflicts: src/core/core.js
-
Mike Bostock authored
-
Mike Bostock authored
-
Jason Davies authored
-
Mike Bostock authored
This makes it easier to override via stylesheet.
-
Mike Bostock authored
-
Mike Bostock authored
It is now possible to reselect elements with scheduled transitions and redefine associated tweens; this enables "post-selection" to customize the behavior of reusable components undergoing transitions, such as an axis. This commit also makes it much easier to sequence transitions. Previously, a transition's tweens were stored privately by the transition and could only be accessed through the transition. This made it impossible to modify transitions created by components: the transition is not accessible externally, and cannot be reselected from the document. Consider the following snippet: g.select(".x.axis") .call(xAxis) .selectAll("text") .attr("dy", null); If `g` is a selection, then this code alters the appearance of the axis as expected. However, if `g` is a transition, then transition.selectAll creates a new concurrent transition, and now multiple tweens compete to set the "dy" attribute. Oy! Under the new design, an element's scheduled tweens are stored semi-privately on the node (in the existing node.__transition__). Transition parameters can thus be reselected and modified by transitions that share the same id. If you now reselect a transitioning element, you modify the transition rather creating a competing transition; this should be less surprising and allow greater control. As a side-effect of this change, it is no longer possible to schedule concurrent transitions on the same element, even with the same id: only one transition may be active on a given element at any time. (Note that you can still schedule multiple future transitions on the same element, and concurrent transitions on different elements.) For example, you could previously schedule overlapping transitions with different easing functions, delays or durations, provided you were careful to avoid conflict. This seems like a relatively obscure use-case compared to modifying a transition, so I believe this is a reasonable change. This commit also changes transition.transition, such that the returned transition starts at the end of the originating transition, rather than overlapping. This makes it much easier to schedule sequenced transitions without the complexity of transition.each("end") and d3.select(this). Also, transitions are now simply arrays of nodes, consistent with selections!
-
Mike Bostock authored
Better resampling for non-linear distortions.
-
- 04 Oct, 2012 3 commits
-
-
Mike Bostock authored
-
Mike Bostock authored
Timer callbacks are now assigned a unique id, such that if an existing callback is later replaced, the timing parameters can be updated using a constant-time lookup rather than a linear scan of the timer queue.
-
Jason Davies authored
I've reinstated the original conditional for linear longitudinal interpolation, since the x * x < ε conditional was not tight enough and hence caused glitches in projections that include the poles e.g. stereographic. Back to solving the issue that was primarily noticeable in the Albers demo: graticules near the poles would not resample correctly. We made an assumption that a point mid-way along the connecting great arc is going to be approximately mid-way in pixel-space. This is a reasonable assumption in most cases, but there is an area of high instability near the poles, since a small change in distance could result in a large change in longitude, e.g. imagine a great arc going right over a pole, so the longitude will change greatly depending on which side of the pole you're on. So the new fix is to see if the distance in pixel-space hardly changed at all, and in this case we attempt to interpolate again, mid-way to the new spherical coordinates. I think we can probably improve this even further by borrowing methods from standard root-finding techniques e.g. Newton-Raphson.
-
- 03 Oct, 2012 3 commits
-
-
Mike Bostock authored
Add extra ring if polygon "surrounds" clip circle.
-
Jason Davies authored
This can be optimised using the 3D coordinates directly from the rotation step, rather than performing additional trig. calculations.
-
Jason Davies authored
The antemeridian interpolator was mistakenly assuming longitudes of interpolation points are exactly on the antemeridian. An alternative fix would be to use exact equality tests for the coincident points test, but it feels safer to use a margin of error.
-
- 02 Oct, 2012 13 commits
-
-
Jason Davies authored
This was breaking antemeridian clipping in some rare cases where a point was coincident with the antemeridian.
-
Jason Davies authored
-
Jason Davies authored
Polygon LinearRings weren't being closed correctly.
-
Jason Davies authored
It was breaking obviously in the resampling demo. Retains a minor optimisation.
-
Jason Davies authored
Interpolation of longitudes becomes inaccurate near the poles, since they become mathematically insignificant in relation to a sphere. However, for map projections, we want to interpolate longitudes even at the poles themselves, since many projections distort the poles along an edge.
-
Jason Davies authored
Conflicts: d3.v2.min.js
-
Mike Bostock authored
This reverts commit b6d7c5e4.
-
Jason Davies authored
Conflicts: d3.v2.min.js
-
Mike Bostock authored
-
Jason Davies authored
-
Jason Davies authored
-
Jason Davies authored
-
Jason Davies authored
Hurrah for tests!
-