Hacker News new | ask | show | jobs
by 1wheel 4489 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.

2 comments

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).