Hacker News new | ask | show | jobs
by Cogito 4480 days ago
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.
1 comments
1wheel 4480 days ago
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.

link
Cogito 4480 days ago
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.

link
dirtyaura 4480 days ago
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.
link
mikaraento 4480 days ago
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).

link