28 comments

[ 1.9 ms ] story [ 74.3 ms ] thread
Pretty cool. Something is wrong in the top left quadrant though, the graph tooltip becomes a little sluggish when it is anchored to the bottom right of the cursor. Might be related to array reversals, etc.
The only thing I could see after a quick look at the source is that

    tooltip.node()
is called twice in the top left quadrant, vs once or never in the other quadrants.

Can't imagine that being the bottle neck, but it seems to be the only non-symmetrical code path. Might try and profile and see if anything pops up.

I would be shocked if that was the cause of any lag - D3 selections are essentially nested wrappers around HTML nodes. .node just grabs the first one in a selection.

https://github.com/mbostock/d3/blob/master/src/selection/nod...

Not sure what else it could be though, unable to duplicate.

For what its worth, I can duplicate on Chrome 33.0.1750.117

The tooltip movement becomes laggy as soon as I move into the top left quadrant. No noticeable difference between any of the other three quadrants.

It seems that in the left-right quadrant it is doing more expensive full-width paints, which explains the lag. It is caused by the small highlight rect, but I couldn't figure out why.
Well that was interesting.

The cost is indeed in the paint (the lagging top-left quadrant redraws the whole map svg).

The difference in the tl and other quadrants is that the other quadrants were causing a synchronous layout because they were asking for the highlight's size to position the tooltip. And this was _faster_, because the different sequencing of layout and paint resulted in a less expensive (partial) paint.

BTW, if you actually want to make this kind of tooltips for complex SVG I recommend having the continuously updated part to be in its own HTML element with styling to make it hardware-accelerated ('div style="-webkit-transform: translate3d(...)'). That way only the changed parts are repainted and the compositing is done by the GPU.

(Well, actually modern IEs are very good at optimizing the SVG changes, but Webkit isn't).

(comment deleted)
Firefox really struggles animating SVGs smoothly with javascript. Wish I knew enough about Firefox's internals to work around it, but basically everything I make suffers from this problem (for example - http://roadtolarissa.com/twisters/)
Look at mainland China in 1990, then click on 2015.
Try going from 2010 to 2015, surely that must not be right
Yeah, I have to agree I tried looking up demographic information about Chongqing and Chengdu and while they do seem to be growing, I didn't see anything that could explain a growth of that magnitude. Maybe it's an artifact of some interpolation method he's using? The source data he linked to seems only to go to 2000, so I'm not sure where the data for 2005 - 2015 came from.
Looks great, and generally very smooth for me.

When the tooltip changes location it is quite jarring, but I have no good solution for that :) - perhaps only flip the position when you would otherwise obscure the underlying visualisation, rather than when you cross the centre? You could then have the tooltip 'push up' to the edge when you navigate close to it, but when the tooltip would otherwise not be obscuring. There was a submission to HN not too long ago that featured a library that would simplify creating this kind of behaviour, but alas I cannot find it.

It took me a while to click on the different years at the bottom, and until I did I wasn't certain what the tooltip data was representing. Probably not a problem, as the discovery was fun, but I guess many might not explore that far.

Out of interest, what were your design thought process when choosing a map projection?

Didn't notice the tool jumping around till you pointed it out; now I can't stop seeing it. Pushing against left and bottom would definitely be better, especially since there isn't much to see there.

Embarrassingly, I'm not sure what the projection is. The data is described as 'estimates of human population for the years 1990, 1995, and 2000 by 30 arc-second (1km) grid cells'. I did some aggregation to reduce the file size and then just converted that grid to pixel values stretched across the screen:

    y = d3.scale.linear()
        .domain([0, longitudes.length])
        .range([0, height]),

http://sedac.ciesin.columbia.edu/data/set/grump-v1-populatio...
I found the projection on the GRUMP FAQ page[0]. Turns out they don't use a projection:

    *Projection: None, the data is in Geographic (latitude/longitude)*
and so the resulting map is similar to the Mercator.

I wonder how easy it is to map lat/long co-ordinates into different projections - would be a cool option to have on all similar maps.

[0] http://sedac.uservoice.com/knowledgebase/articles/41635-what...

Nicely done but I'm not sure the spikes are a better fit for this than an ordinary heat map would be.
Heat maps aren't always easy to make sense of for colorblind people like myself.
This is the best population visualization I've ever seen. It's striking that spikes turned out to be so superior to heatmaps. It's possible to intuit the whole dataset at a glance, whereas heatmaps force you to constantly worry about the meaning of every color in relation to every other color.

It's obvious in retrospect why spikes are superior: precision. Spikes represent the underlying data much more accurately than colors, especially between datapoints.

Problem with spikes is that they hide the information behind them. Heatman doesn't.
Heatman would never do that. Heatman honest.
This is surprisingly slow on my computers whereas other WebGL stuff are rendered pretty well. I guess that's the cost of doing things with SVG.
Neat!

Would be interesting to see predictions through say 2100 or 2200 maybe with different models.

IIRC the current predictions are we'll peak around 2050-2060 after which world population will start declining. That assumes that as countries become more affluent they start having less and less children which leads to a population decline. IDK if those models take into account longer lifespans.

http://en.wikipedia.org/wiki/Projections_of_population_growt...