nsSVGForeignObjectFrame::PaintSVG doesn't pass aDirtyRect through

RESOLVED FIXED in mozilla1.9.3a1

Status

()

defect
P3
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

({perf})

Trunk
mozilla1.9.3a1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

I was investigating why fixing bug 418063 didn't make much of an improvement on the performance problems in:
http://dbaron.org/mozilla/invert-colors#http://tests.themasta.com/tinderboxpushlog/?tree=MozillaTry

I think I've found the next (maybe even last, I hope) problem, which is that nsSVGForeignObjectFrame::PaintSVG doesn't pass a transformed version of aDirtyRect through to the call to nsLayoutUtils::PaintFrame; it just tells PaintFrame that everything is dirty.
Posted patch patch (obsolete) — Splinter Review
This patch seems to work; it makes things involving repainting in foreignObject feel *much* faster.

I found this code (and the GetFrameForPoint code) somewhat confusing, but I think I understand it now.  However, now that I understand it, I'm not quite sure how to make it simpler, though I think it should be.

I've tested that the repainting from selection and link hovering works in http://starkravingfinkle.org/blog/wp-content/uploads/2007/07/foreignobject-transform.svg (including when zoomed), and in a similar testcase that has a viewbox.  I should probably have some automated tests for those combinations, though...
(In reply to comment #0)
> I was investigating why fixing bug 418063 didn't make much of an improvement on
> the performance problems in:
> http://dbaron.org/mozilla/invert-colors#http://tests.themasta.com/tinderboxpushlog/?tree=MozillaTry

That's no longer a testcase for this, since I reworked it to avoid using foreignObject (it uses 'filter' on HTML elements instead).
When I pushed to try, I got this failure on Mac only:
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/sendchange-macosx-unittest/mozilla/layout/reftests/svg/moz-only/foreignObject-zoom-01.svg |
... seems like it could be a real problem.  (Not sure if it's this bug or bug 418063's patch.)
testcases for this patch are in bug 426980 bug 428379 and bug 484677

It may be possible to turn the first two into reftests using roc's zoomed reftest feature. If the first two bugs still work then it's pretty certain that bug 484677 still will.
Posted patch mac reftest failure (obsolete) — Splinter Review
This is the reftest failure from try server; I confirmed it is due to this patch, and it's happened twice.  It's Mac-only.

The problem is a very slight color difference down the right edge of the viewport.

I expect I need a call to ToOutsidePixels somewhere.
Posted patch patchSplinter Review
The cause of the reftest failure was that I was inadvertently using the default conversion (truncate) of floats to nscoord rather than using NSToCoordFloor/Ceil as appropriate.
Attachment #422861 - Attachment is obsolete: true
Attachment #423118 - Attachment is obsolete: true
Attachment #423720 - Flags: superreview?(roc)
Attachment #423720 - Flags: review?(jwatt)
Also, I wonder if we should really be intersecting the dirty rect with the kid's rect (which is what we used to pass as the dirty rect); maybe we shouldn't.  I should write some tests...
Attachment #423720 - Flags: superreview?(roc) → superreview+
(In reply to comment #8)
> Also, I wonder if we should really be intersecting the dirty rect with the
> kid's rect (which is what we used to pass as the dirty rect); maybe we
> shouldn't.  I should write some tests...

It seems like we're always clipping the overflow, so it doesn't matter.
Attachment #423720 - Flags: review?(jwatt) → review+
http://hg.mozilla.org/mozilla-central/rev/bbc58a03cab9
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Priority: -- → P3
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
You need to log in before you can comment on or make changes to this bug.