[Webkit-unassigned] [Bug 12007] SVGColor::setRGBColor color creates/deletes many strings, slowing down parsing

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=12007





------- Comment #1 from macdome at opendarwin.org  2006-12-27 16:39 PDT -------
Thinking about this more, it isn't at all surprising that color parsing is our
current hot spot.  What do SVG parsers/renderers do?  Parse lots of colors and
lots of paths.  I expect even with Rob's improvements, this area will get hot
again soon.

One of the major flaws in the current paint parsing/color parsing is how all
parsing is done in the constructors.  That means you have to call new SVGPaint
just to figure out if the string you have even has a valid color/paint in it. 
That's silly.  We should parse the string first, then wrap it in a paint if it
happens to be valid.

Ideally we would unify HTML and SVG color parsing.  There is little reason why
'aliceblue' should work in SVG and not in HTML for instance.  I believe the set
of named colors is the only difference between SVG and HTML colors.  We could
pass a bool into the common color parsing function to disable certain colors
when parsing HTML if deemed necessary.

Rob's fix will work.  A long term solution will involve removing all the
SVGPaint allocations and only allocating after parsing once we've determined we
have a valid Color/SVGColor.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.