Summary: | gearflowers.svg renders incredibly slowly in Safari | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | ian | ||||
Priority: | P4 | ||||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
URL: | http://me.in-berlin.de/~darwin/svg/incoming/gearflowers.svg | ||||||
Bug Depends on: | 6052 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Eric Seidel (no email)
2005-12-12 23:58:37 PST
Created attachment 5124 [details]
Profile of gearflowers.svg being rendered
Part of this is that it is a 521k file on a slow server. A local copy takes on
order of 3 seconds to render on a dual 2 GHz G5 here. 7.9% of the time is
consumed in CoreGraphic's getNextAxialShadingScanline, which may be somewhat
optimizable. Other gradient-related functions are taking up a significant chunk
of time, athough the only WebCore function is cgGradientCallback.
See attached shark profile.
Well, it's now part of our newly-landed SVG page load test. Part of this is also a CG performance bug in shadings, which I expect will be addressed in a future OS release. I filed a Radar with CG while I was still at apple about exactly this issue. CG Gradients are incredibly slow. We might just replace them with our own gradient code if we can't get a better API from them (functional based gradients make things way way way slower than they need to be) or see the perf issues with the existing gradient API addressed. It would be nice to see that radar number associated with this bug (or a new one filed). It's definitely better in leopard. I'm not sure this bug is super-useful anymore. |