Qt SVG renderer

[Matthew Woehlke]

Tor Arne Vestbø wrote:
> Tor Arne Vestb� wrote:
>> I'd be happy to publish the results when I'm done.
> 
> Here are the results:
> 
> http://chaos.troll.no/~tavestbo/svg/

Thanks for this awesome chart! As Rafael said, I'm a bit surprised that 
WebKit seems to be *worse* in several ways, it looks like maybe it does 
not support object opacity? Main issues I see in QtSvg are no masking, 
non-XOR path drawing not supported, and of course lack of blur.

I think it would be nice if your "compare" frame was gradiated so that 
the dithering artifacts aren't so visible (after all, it's acceptable if 
QtSvg and librsvg use different dithering algorithms!). Instead of 
white->pixels match, black->pixels differ, maybe you could convert both 
to grayscale, do a subtractive overlay, and apply levels/curves to the 
results to enhance the differences, but still leave minor differences as 
light gray instead of black. I think this would give a better idea of 
how "close" QtSvg is (and also provide a better metric to mechanically 
measure correctness, i.e. if any final pixels are darker than X, flag it 
as a problem, but lighter than X can be treated as "good enough").

What's a little concerning are ones like application-x-executable where 
librsvg is clearly wrong (and, in fact, QtSvg is closer to right). Given 
that I've also seen some where Batik messes up (but librsvg doesn't), 
that says to me that inkscape is still the closest thing to a 
"canonical" render (or else, our svg's are wrong somehow). And then 
there's application-x-java-applet, for which *none* of the renders bears 
hardly even a passing resemblance to inkscape's rendering.

-- 
Matthew
Did you hear about the pig that makes footwear for cows? He's a real moo 
shoe pork.