Open Tanner opened 11 years ago
It's a bit slower on my 4-year-old computer. I can put binary search in there using a sorted detonations variable.
Sounds good. The offending part is in brushmove()
:
function brushmove() {
var s = d3.event.target.extent();
detonationBars.classed("selected", function(d) {
var year = d["year"];
return s[0] <= year && year <= s[1];
});
detonations.classed("shown", function(d) {
var year = d["formattedDate"];
return s[0] <= year && year <= s[1];
})
.transition()
.attr("r", function(d) {
var year = d["formattedDate"];
var present = s[0] <= year && year <= s[1];
return present ? detonationYieldRadius(d) : 0.0;
});
}
I attempted to make it faster by storing the array of detonation objects by only performing the lookup once (the detonations shown will never change). So there is a starting point.
I'm not quite sure what method d3 uses to iterate through, but I'd imagine binary search would be a good help.
The point of using binary search would be to pinpoint the indexes of detonations (sorted by year) at which the slider handles changed right? (So that only the detonations that were just brushed over or not could have their respective attributes changed?) That would sort of be like the bit of optimization I did with the jQuery slider.
If you select an area on the timeline and slide it, i.e. dragging on the highlighted area (not making it bigger, just moving it), the selected area kinda hangs behind.
This is due to the changing of the all the detonation radii. Sadly, there's 2k detonations and d3 has to go through each one of those to see if they need to be shown or not.
(Course if we turn off the change in radius for the detonations the issue goes away, but that defeats the point of having the timeline)
It's not bad for me, but it could be bad on some computers. I'm not quite sure how to resolve this.
One possible solution is a binary search on a sorted (by year) list of detonations. That could speed things up a bit.