[webkit-dev] Running pixel tests on build.webkit.org

[Nikolas Zimmermann]

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
>>> <zimmermann at 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