Created attachment 274346 [details] 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?
11 years ago
I see pretty dismal perf on mac as well... does that warrant a separate bug?
Probably yes. It _might_ end up being the same issue in our code or cairo, but it might not.
Summary: Terrible performance on vlad's SVG Photos demo → Terrible performance on vlad's SVG Photos demo on Linux
11 years ago
Filed bug 390035 on the Mac performance issue.
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.
Ah. I'd always started with scaling up, the better to see what I was doing... Can we get bugs pushed upstream as needed?
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-18.104.22.168-9.fc7 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) "intel" driver
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.
Old bug -- amusingly, since I'm back at Mozilla, the original link works again :)
WFM on Mac. Daniel, would you mind testing this and comparing to Chrome on Linux?
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?
Flags: needinfo?(dholbert) → needinfo?(jwatt)
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.