Painting of the difference highlighting in reftest analyzer got really slow

RESOLVED FIXED in mozilla20

Status

()

defect
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: bzbarsky, Assigned: jfkthame)

Tracking

({regression})

unspecified
mozilla20
x86
macOS
Points:
---

Firefox Tracking Flags

(firefox18-, firefox19-, firefox20-)

Details

()

Attachments

(1 attachment)

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).
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.
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.
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.)
Attachment #685735 - Flags: review?(bzbarsky)
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 on attachment 685735 [details] [diff] [review]
speed up reftest-analyzer by avoiding use of a large dilation radius

r=me, I guess.
Attachment #685735 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d18ded60330
Assignee: nobody → jfkthame
Target Milestone: --- → mozilla20
https://hg.mozilla.org/mozilla-central/rev/9d18ded60330
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Good perf fix to take alongside the HiDPI feature. Please nominate for uplift when comfortable with the landed change.
Note that this improved the performance of the reftest analyzer itself, not the underlying SVG feature it was using.
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
Untracking given comments 9 and 10.
You need to log in before you can comment on or make changes to this bug.