[Webkit-unassigned] [Bug 38851] Large SVG rect with shadow fails to render

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Nikolas Zimmermann <zimmermann at kde.org>  2010-05-30 04:29:40 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > Created an attachment (id=57415)
 --> (https://bugs.webkit.org/attachment.cgi?id=57415) [details] [details]
> > Patch
> 
> This patch causes no regressions in the svg test results, so I didnt upload any changed results.
> Cheers,

Hey Rob,

this patch still puzzles me. I don't know why we actually have to clamp to intmax??
If we just get rid of any intermediate integers, we can use floatmax no?

Just a quick test:
float floatMin = std::numeric_limits<float>::min();
float floatMax = std::numeric_limits<float>::max();
std::cout << "FLOAT min=" << floatMin << " max=" << floatMax << std::endl;

int intMin = std::numeric_limits<int>::min();
int intMax = std::numeric_limits<int>::max();
std::cout << "  INT min=" << intMin << " max=" << intMax << std::endl;

Result:
FLOAT min=1.17549e-38 max=3.40282e+38
  INT min=-2147483648 max=2147483647


If you just store shadowLeft/shadowRight and shadowBottom/shadowTop in float values (changing getSVGShadowExtent to operator on floats, not integers), then following code should just work, no?

repaintRect.move(shadowLeft, shadowRight);
repaintRect.setSize(repaintRect.size() + FloatSize(shadowRight - shadowLeft, shadowBottom - shadowTop));

That would remove the need for the intermediate overflow* values, and we wouldn't need to clamp to just integer range, which sounds wrong to me.

Cheers,
Niko

P.S. Not setting r-, to discuss this a bit further.

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