936472 - Slow SVG hit-testing performance on D3.js based Rotate the World

Status: RESOLVED WORKSFORME

(Core :: SVG, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

URL: http://www.jasondavies.com/maps/rotate/

BUILD: Today's nightly

STEPS TO REPRODUCE:  Try dragging to rotate the globe.

ACTUAL RESULTS: Slightly more laggy than Chrome and Safari

EXPECTED RESULTS: We rule.

A profile shows about 13% of our time under ProcessSynthMouseMoveEvent (all under hit testing) and 23% under FindFrameTargetedByInputEvent when handling the actual mouse events.  In both cases, the time is all under gfxContext::PointInStroke, called from nsDisplaySVGPathGeometry::HitTest via nsSVGPathGeometryFrame::GetFrameForPoint.

Under PointInStroke, it's pretty much all under CGContextReplacePathWithStrokedPath.

Comment 2

[Jonathan Watt [:jwatt]]

Right now I can't test due to the error following error preventing the dragging code from running:

  TypeError: d3.event.sourceEvent.preventDefault is not a function

Comment 3

[Jason Davies]

I've fixed the d3.event.sourceEvent.preventDefault error for you.  Let me know if I can do anything else to help.

Comment 4

[Jonathan Watt [:jwatt]]

Ah, thanks, Jason.

Comment 5

[Jonathan Watt [:jwatt]]

How do you find the performance now, Boris. I'm struggling to see a difference on my Mac.

I did profile all the same: https://perfht.ml/2nLYvGK

Looks something like:

  60%  JS::Call
   5%    setAttribute('d', ...)
  19%  nsDisplayList::PaintRoot
  12%  nsLayoutUtils::GetFrameForPoint

The page draws the globe using only four path elements (one for an outline, one for the grid, one for country borders and one for landmass fill). The path data is very long and the bounds of each path is essentially the entire globe (we can't avoid hit testing the paths), so it's not very surprising that we spend so much time hit-testing.

It's also not surprising that there's nothing in the profile really for display list/layer building and processing given there are essentially only four elements.

What I do find a bit surprising is that so much time is spent in JS code. Digging around it didn't seem like much of that time was attributable to DOM calls other than setAttribute, but I might be missing things since the stacks are insanely deep.

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Watt [:jwatt] from comment #5)
>   60%  JS::Call

I just filed bug 1349159 for another example where JS engine slowness seems to be the culprit for things being slower than Chrome rather than SVG/painting.

Comment 7

[Boris Zbarsky [:bzbarsky]]

On my Mac, I likewise don't see any more lag here...  Some of this is faster hardware, no doubt, some whatever code changes happened in the last 9 years.  ;)