815617 - Painting of the difference highlighting in reftest analyzer got really slow

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Boris Zbarsky [:bzbarsky]]

STEPS TO REPRODUCE:

1)  Load URL in URL field.
2)  Click the one failing test in the list on the left.
3)  Check the "Circle differences" checkbox.

EXPECTED RESULTS: Browser is still snappy.

ACTUAL RESULTS: Browser gets very laggy; every repaint of that tab takes multiple seconds.

ADDITIONAL INFORMATION:

Bisecting on nightlies gives me http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c09a0c022b2e&tochange=a680fd777c3b which has the HiDPI changes (could be relevant; I'm on a high-dpi MacBook) but also a few other graphics things.

Sampling my nightly via ActivityMonitor says all the time is under painting, and in particular under nsSVGFEMorphologyElement::Filter (called from nsSVGFilterInstance::Render, called from nsSVGFilterFrame::PaintFilteredFrame).

Comment 1

[Jonathan Kew [:jfkthame]]

If I disable hidpi rendering (gfx.hidpi.enabled = 0), the lagginess isn't nearly so bad, though it still feels rather sluggish. Which makes me suspect that the "circle differences" display is inherently slow, but it's exacerbated by being in hidpi mode - maybe there's some O(n^2) algorithm that depends on the number of (device) pixels in the area being filtered, or something like that.

Comment 2

[Jonathan Kew [:jfkthame]]

Well, it wouldn't even need to be O(n^2), actually. The fact that it's handling 4x the number of pixels might be enough to make the difference between feeling "rather sluggish" and "very laggy".

We should investigate whether the performance in non-hidpi mode has degraded; and whether the difference is simply 4x, or worse.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: speed up reftest-analyzer by avoiding use of a large dilation radius

A little playing around with reftest-analyzer.xhtml seems to indicate that the dilation operation is particularly expensive, and that increasing the dilation radius dramatically increases the time taken. Hence, hacking the file to reduce the dilation used will significantly improve performance. (This does make the red highlighting thinner than it was, but I think it's still adequately visible.)

Comment 4

[Jonathan Kew [:jfkthame]]

Of course, making the dilation filter really fast would be preferable, but this at least provides a workaround to make reftest-analyzer less painful.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 685735 [details] [diff] [review]
speed up reftest-analyzer by avoiding use of a large dilation radius

r=me, I guess.

Comment 6

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9d18ded60330

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9d18ded60330

Comment 8

[Alex Keybl [:akeybl]]

Good perf fix to take alongside the HiDPI feature. Please nominate for uplift when comfortable with the landed change.

Comment 9

[Cameron McCormack (:heycam)]

Note that this improved the performance of the reftest analyzer itself, not the underlying SVG feature it was using.

Comment 10

[Daniel Holbert [:dholbert]]

Yeah, there's no benefit (though also no harm) in tracking this change (or accepting the patch) on branches. The reftest analyzer is publicly available here:
http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml

If we want this on branches, it can land with a=NPOTB

Comment 11

[Alex Keybl [:akeybl]]

Untracking given comments 9 and 10.