Talos tsvgr_opacity regression when SVG display lists enabled

RESOLVED FIXED in mozilla17

Status

()

Core
SVG
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

({perf})

Trunk
mozilla17
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Testing locally, small-group-opacity-2500.svg seems to take 5x or so longer to render when SVG display lists are enabled. I thought at first this must be because the group opacity optimization wasn't working correctly with display lists, but in fact we can't even use that optimization for this test, so that's not it. Needs some investigation.
(Assignee)

Comment 1

5 years ago
Created attachment 647771 [details] [diff] [review]
patch
Attachment #647771 - Flags: review?(roc)
(Assignee)

Comment 2

5 years ago
For the record, the problem is that when SDL is enabled, we create an nsDisplayOpacity item to handle the group opacity on all the rects. When painting through that we end up under BasicLayerThebes::PaintThebes where we call BasicLayerManager::PushGroupForLayer, which calls gfxContext::PushGroupAndCopyBackground. The PushGroupAndCopyBackground call spends virtually all its time in _moz_cairo_paint is much more expensive than the PushGroup call (which doesn't call _moz_cairo_paint) we make in the SDL-disabled path. In fact it takes up 80% of the paint time. A PushGroup call in comparison is virtually free.
(Assignee)

Updated

5 years ago
Keywords: perf
Attachment #647771 - Flags: review?(roc) → review+
(Assignee)

Comment 3

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d3c9b863c69
Target Milestone: --- → mozilla17
(Assignee)

Comment 4

5 years ago
Thanks, roc!

Comment 5

5 years ago
https://hg.mozilla.org/mozilla-central/rev/9d3c9b863c69
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.