[Webkit-unassigned] [Bug 42387] SVG - stroke-width:0 bug with stroke other than "none"

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=42387





--- Comment #27 from Fady Samuel <fsamuel at chromium.org>  2010-07-28 10:33:17 PST ---
(In reply to comment #26)
> (In reply to comment #24)
> > > Great patch! Just some notes. IIRC the default for stroke-width is not 1px but 1. So no need for SVG_RS_DEFINE_ATTRIBUTE_DATAREF_WITH_INITIAL_REFCOUNTED2.
> 
> Quote, from SVG spec: "One px unit is defined to be equal to one user unit. Thus, a length of "5px" is the same as a length of "5"."
> 
> > > 
> > I'm confused by this comment. I still need a default CSSPrimitiveValue, do I not? Previously the default was NULL, which translated into stroke-width:0 throughout the code. What UnitType is appropriate here?
> 
> As stroke-width is a CSSValue and as you need a default value of "1", using "1px" is fine. Though the new macro is wrong. You're not allowed to create a static local CSSValue! That's a bad idea, the render style is shared, that would lead to problems.
> 
> The real fix is to move away from storing CSSValue in SVGRenderStyle. As you may have noticed, RenderStyle doesn't do that for HTML/CSS properties. It's a special old SVG solution.
> 
> We really want to store floats for things like stroke-width / stroke-dashoffset, the problem is how to handle percentage values. If you grep for cssPrimitiveToLength, you'll see constructs like:
> float strokeWidth = SVGRenderStyle::cssPrimitiveToLength(this, svgStyle->strokeWidth(), 1.0f);
> in RenderPath.cpp as example.
> 
> cssPrimitiveToLength contains special code to handle percentage values, as they have to be evaluated relative to the viewport (as SVG defines it).
> 
> I need to think more about this, but it's a good opportunity to cleanup SVGRenderStyle/Defs which is a crude hack at the moment, so much macro usage.
> 
> Need to leave for today, maybe we can find some time to chat on IRC.
> I'd encourage you to cleanup SVGRenderStyle/Defs first, before doing any further work on it. A good first step would be to remove the macro usage alltogether, there's even a FIXME for that.
> 
> Do you have some time to work on this?

So this sounds like a lot of work, but I can continue to work on it. So a simple solution for removing macros would be to simply expand all the macros, but I doubt that's what you had in mind. Will discuss this further on IRC.

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