Am 09.01.2010 um 18:09 schrieb Maciej Stachowiak:
On Jan 9, 2010, at 6:35 AM, Nikolas Zimmermann wrote:
Am 08.01.2010 um 22:32 schrieb Evan Martin:
On Thu, Jan 7, 2010 at 4:05 PM, Nikolas Zimmermann
<zimmerm...@physik.rwth-aachen.de> wrote:
How about we'd start only with svg/ pixel tests? Getting SVG
pixel tests
working across the ports
would be a huge leap forward.
One caveat: at least on Linux Chrome we've found that we get
slightly
different pixel results for some SVG tests in curves depending on
whether we're 64 or 32-bit. It problem could be in Skia, though.
You should pick whether your baselines are gonna be 32 or 64 and
then
add exceptions for the other; in Chrome we didn't notice we were
mixing for a while and rebaselined some results over themselves a
few
times.
I am partly aware of this problem (regarding 64 vs 32. bit) it
affects non-linux platforms as well,
the root of the issue is that Path::debugString() does NOT have an
cross-platform implementation,
but instead every platform manually dumps the path elements. For CG
we see 0.0 vs -0.0 differences
for certain paths - the whole problem is easily fixable though.
Anyone wants to volunteer? :-)
What does it take to fix it?
WebCore/platform/graphics/cg/PathCG.cpp -
CGPathToCFStringApplierFunction function.
It's just manually traversing the path elements, and we could easily
implement that in a cross-platform manner,
fixing the 32 vs 64 bit bugs in one go.
Also, I believe that 0.0 vs. -0.0 in a path will never actually
result in different layout. And I don't believe this has ever
identified a real bug. So perhaps we should dump all zeros as
positive 0.
This is true, it's just a layout test result difference.
Cheers,
Niko
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
