Repainting is incredibly slow. Seems to be the chart, which is a giant array of different <circle> elements, with attributes like this: style="stroke-width: 1px; stroke-opacity: 0.3; opacity: 0.1;" fill="rgb(255,255,191)" cy="632" cx="1156" r="1.2516075675515137" and CSS rule stroke: rgb(255, 255, 255);

On Mac, it seems like I fixed this in bug 766429. Can someone check Windows? Before: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-20-06-51-38-mozilla-central/ After: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/06/2012-06-21-03-05-36-mozilla-central/

checking...

I checked before and after on my work machine and an old laptop. There is an order of magnitude improvement with jwatt's changes, and perf is good on my dev machine, but it still runs like a dog on the old laptop (and it's not that underpowered, the page is fine in Chrome). So I think it is worth having a bit of a poke around at this.

You should also check very latest m-c too, since I've landed more perf improvements since then. I don't expect those to have helped here, but best to check.

Comment on attachment 637789 [details] [diff] [review] hit testing change by roc Please use GetVisualOverflowRect instead of GetCoveredRegion. That means converting the point to frame space, but nsSVGUtils::TransformOuterSVGPointToChildFrame will help you there. r+ with that.

What I was actually going to do here as follow-up to bug 734082 was change GetFrameForPoint so that the point passed to it is already in frame space. That would actually be better, since TransformOuterSVGPointToChildFrame involves some overhead calculating the transform to the nsSVGOuterSVGFrame. I don't suppose you feel up to doing that, do you?

I'll give it a go, probably time I learnt a little about the SVG code. I've got a bunch of stuff on at the moment though, so might take a while.

I'm wondering if it's worth spending time on this given that bug 614732 will essentially do the same thing by only walking into containers to build hit-test display list items if the container's if the hit point is in a containers' visual overflow rect. I'm not opposed to it, but with that point in mind, maybe there are more important bugs to fix?

nrc, does this work for you now?

(In reply to Jonathan Watt [:jwatt] from comment #10) > nrc, does this work for you now? Not really, it is still really, really slow. Assigning to you, but feel free to WONTFIX it if you want.

Unfortunately the link is now dead. Comment 3 says we got order of magnitude improvement, so that's something at least.