Closed Bug 541188 Opened 15 years ago Closed 14 years ago

nsSVGForeignObjectFrame::PaintSVG doesn't pass aDirtyRect through

Categories

(Core :: SVG, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1

People

(Reporter: dbaron, Assigned: dbaron)

References

()

Details

(Keywords: perf)

Attachments

(2 files, 2 obsolete files)

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.
Attached 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.
Attached 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.
Attached 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
Closed: 14 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.

Attachment

General

Created:
Updated:
Size: