For example: fast/borders/borderRadiusArcs01.html svg/W3C-SVG-1.1-SE/pservers-pattern-04-f.svg fast/backgrounds/body-generated-image-propagated-to-root.html
Hundreds of tests with skia drawing are affected by this bug, e.g. svg-tests, round-corner, gradient, etc. On Tue, Jun 7, 2011 at 11:58 PM, Dirk Pranke <[email protected]> wrote: > Reftests? > > -- Dirk > > On Mon, Jun 6, 2011 at 11:00 PM, Hao Zheng <[email protected]> wrote: >> Unfortunately, even for SVG or images, different drawing >> implementations will lead to different pixel results. Like this Skia >> bug, http://code.google.com/p/skia/issues/detail?id=179 , which caused >> most pages using SkFixed calculation, e.g. round-corner, gradient, >> svg, etc., produce different rendered image on different platforms. So >> I think there are many subtle, if possible, issues to make pixels >> consistent across all platforms. >> >> On Tue, Jun 7, 2011 at 1:23 PM, Eric Seidel <[email protected]> wrote: >>> So are we saying it's impossible to have matching results across all >>> platforms if a test involves any text (in any font)? >>> >>> I know it's certainly possible to have pixel-results for tests which >>> do not involve text match across all platforms (like SVG or images or >>> css styling, etc.) >>> >>> Or is all this just theory? >>> >>> -eric >>> >>> On Mon, Jun 6, 2011 at 8:09 PM, Hao Zheng <[email protected]> wrote: >>>> Yes, actually in Skia, Chromium/Linux uses a noop gamma implementation >>>> in SkFontHost_gamma_none.cpp; however, if you use a substantial >>>> implementation in SkFontHost_gamma.cpp, there will be much image >>>> mismatch on Chromium/Linux for every font including Ahem. The slight >>>> differences are on font fringe. >>>> And I think if other WebKit is not using Skia at all, there will >>>> surely be even more differences. >>>> >>>> As the gamma implementation on Clank is desired, we should not fix >>>> this bug. Just file the bug to record this difference. >>>> >>>> On Fri, Jun 3, 2011 at 2:30 AM, Tony Chang <[email protected]> wrote: >>>>> Perhaps, but in practice, it's not enough. Here's an ahem pixel test that >>>>> is slightly different on Mac and Chromium Linux: >>>>> http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/block/basic/010-expected.png >>>>> http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium-linux/fast/block/basic/010-expected.png >>>>> >>>>> Also, I think it would be hard to tell by examining the HTML if a test >>>>> uses >>>>> another font. For example, the line height of an empty block might depend >>>>> on the default font that isn't specified (does <pre></pre> render the same >>>>> height on all platforms?). >>>>> On Thu, Jun 2, 2011 at 10:44 AM, Adam Barth <[email protected]> wrote: >>>>>> >>>>>> I thought the whole point of Ahem was to avoid those problems. >>>>>> >>>>>> Adam >>>>>> >>>>>> >>>>>> On Thu, Jun 2, 2011 at 1:29 AM, Hao Zheng <[email protected]> wrote: >>>>>> > Actually, even the same Ahem font will be rendered differently on >>>>>> > different platform, depending on the font drawing library, the >>>>>> > anti-aliasing algorithm, subpixel, tiny float-point calculation diff >>>>>> > on different arch. >>>>>> > >>>>>> > On Thu, Jun 2, 2011 at 3:30 AM, Eric Seidel <[email protected]> wrote: >>>>>> >> I know that Ahem is safe to use across multiple platforms (the font >>>>>> >> metrics >>>>>> >> will be the same). Do we know if there are any other fonts for which >>>>>> >> this >>>>>> >> is true? >>>>>> >> I'd like to make the style-bot yell at people when they use pixel >>>>>> >> tests >>>>>> >> with >>>>>> >> non-safe fonts. Right now that list would only include ahem. >>>>>> >> -eric >>>>>> >> _______________________________________________ >>>>>> >> webkit-dev mailing list >>>>>> >> [email protected] >>>>>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>>> >> >>>>>> >> >>>>>> > _______________________________________________ >>>>>> > webkit-dev mailing list >>>>>> > [email protected] >>>>>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>>> > >>>>>> _______________________________________________ >>>>>> webkit-dev mailing list >>>>>> [email protected] >>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>> >>>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
