[webkit-dev] Problems porting layout tests to linux

Jean-Charles VERDIE jcverdie at origyn.fr
Fri Sep 1 01:12:52 PDT 2006

Hi Krzystof,

We had this idea, but it brings a new problem: Let's imagine that we
tolerate a 2 px error. Let's imagine, again, that for one specific test, the
rendered test is 1 px smaller than the reference. Everything's ok. But then
I make some very bad change to the code and tomorrow's build brings that the
same test is now 1 px bigger. Still on the road, but the regression would
not be detected...

Another (bigger) issue : the fuzz factor is a kind of a chain reaction : if
my first block is 2 px bigger, the second block will begin 2 px after the
expected position, if it is still 2 px bigger, the next one will begin 4 px
after the expected position, and so on and so on...

On 8/31/06, Krzysztof Kowalczyk <kkowalczyk at gmail.com> wrote:
> On 8/31/06, Jean-Charles VERDIE <jcverdie at origyn.fr> wrote:
> > We imagine a solution which is to drop our goal to fix the problem, and
> > instead generate  "linux"-based -expected.txt files and to modify dump
> > render tree to either chose osx or linux -based expected files,
> depending on
> > the platform we are testing on.
> >
> > This solution has a major drawback, which is that it will force the
> > community to maintain two version of expected files for every single
> test.
> >
> > Before starting to work in this direction, I'd appreciate some feedback
> on
> > the feeling about this solution, and may be, fortunately, others ideas
> on
> > how to remove this roadblock.
> It would probably be an ugly hack, but looking at the diff it looks
> like all differences are for sizes and fall within 1-2 pixels. How
> about a fuzz factor (either as percent of the total original size or
> in pixels) and accepting failures for sizes orginated from text
> rendering if they fall within fuzz factor? Fuzz factor would be best
> determined empirically (i.e. by comparing current linux vs. mac
> differences and choosing a factor that makes them pass).
> The thinking is that a major breakage would still be detected as
> falling outside of fuzz factor.
> -- kjk

Jean-Charles Verdié
Origyn Web Browser for Embedded Systems Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/webkit-dev/attachments/20060901/9d8b8314/attachment.html

More information about the webkit-dev mailing list