390022 - Terrible performance on vlad's SVG Photos demo on Linux

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Attachment: zipped-up profile

STEPS TO REPRODUCE:

1)  Load URL
2)  Try to move the photos around, resize them, etc

EXPECTED RESULTS:  Snappy response, of course!

ACTUAL RESULTS:  Very laggy.

Looking at "top", we're using about 30-35% of CPU, and X is using the rest.

I did a profile with --sync, which I am attaching.  In brief, pretty much all the time is under nsSVGUtils::PaintChildWithEffects.  It's split about 5:2 between nsSVGImageFrame::PaintSVG and gfxContext::Paint.

Under nsSVGImageFrame::PaintSVG the split is about 3:2 between nsSVGUtils::CompositeSurfaceMatrix (which just calls gfxContext::Paint) and nsSVGUtils::SetClipRect.

Tracing this stuff down into cairo, the split is about 3:2:2 between _cairo_surface_fallback_paint (called eventually from _moz_cairo_paint_with_alpha), _moz_cairo_clip (from SetClipRect), and _clip_and_composite (called eventually from _moz_cairo_paint_with_alpha).

The  _cairo_surface_fallback_paint and _clip_and_composite both largely end up in _cairo_surface_composite.  Those end up largely in XRenderComposite.  Clipping ends up largely in XRenderCompositeTrapezoids and XRenderComposite.

In general, about 16% of total painting time is under XRenderCompositeTrapezoids and the rest under XRenderComposite.

I'm not sure whether we can improve something here in SVG, or in cairo, or whether it's just all XRender issues.  In particular, I wouldn't expect setting a clip rect to take nearly this long, but maybe we're clipping something very complex?  A non-sync profile shows a lot of time waiting on X under gfxContext::Stroke while rendering a path.  So maybe clipping this path takes a long time or something?

Comment 1

[Benjamin Smedberg]

I see pretty dismal perf on mac as well... does that warrant a separate bug?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Probably yes.  It _might_ end up being the same issue in our code or cairo, but it might not.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Filed bug 390035 on the Mac performance issue.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It's almost certainly all Render -- you'll note that if you grab a photo and scale it down so that it's small, you can flip it around fairly quickly, but it gets bogged down as you scale it up; it's just significant per-pixel rendering cost.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah.  I'd always started with scaling up, the better to see what I was doing...

Can we get bugs pushed upstream as needed?

Comment 6

[tor]

With sysprof I'm seeing 93.3% of the system time going into XAAComposite inside the X server.  Most of the time that winds up in fbCompositeGeneral (91.96% of total system time).

Fedora 7
xorg-x11-server-Xorg-1.3.0.0-9.fc7
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04)
"intel" driver

Comment 7

[Jonathan Watt [:jwatt]]

The link in the URL field is dead. Vlad, do you still have those files? If not, can you just close this as incomplete? Thanks.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Old bug -- amusingly, since I'm back at Mozilla, the original link works again :)

Comment 9

[Jonathan Watt [:jwatt]]

WFM on Mac. Daniel, would you mind testing this and comparing to Chrome on Linux?

Comment 10

[Daniel Holbert [:dholbert]]

The demo seems great to me on my Linux laptop, on both Firefox Nightly (fresh profile) and Chrome dev edition.

(Both show high CPU usage in "top" while I am actively changing the zoomlevel of a photo by dragging its corner. And  both seem quite responsive/smooth.)

Shall we close as WFM?

Comment 11

[Jonathan Watt [:jwatt]]

Sounds good.