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