My experience is that having a non-zero tolerance makes maintaining the
pixel results *harder*. It makes it easier at first of course. But as more
and more tests only pass with a non-zero tolerance, it gets harder to figure
out if your change causes a regression (e.g. your change causes a pixel tes
Am 12.10.2010 um 22:43 schrieb James Robinson:
To add a concrete data point, http://trac.webkit.org/changeset/69517
caused a number of SVG tests to fail. It required 14 text
rebaselines for Mac and a further two more for Leopard (done by Adam
Barth). In order to pass the pixel tests in C
Does it support pixel test updates? Is it possible to extend this tool if not?
This would limit the maintenance cost and every commiter should rebaseline mac
if the change is a progression, or the difference is machine dependent
(but not OS dependent).
Dirk
Am 12.10.2010 um 22:49 schrieb Adam B
On Tue, Oct 12, 2010 at 1:43 PM, James Robinson wrote:
> To add a concrete data point, http://trac.webkit.org/changeset/69517 caused
> a number of SVG tests to fail. It required 14 text rebaselines for Mac and
> a further two more for Leopard (done by Adam Barth). In order to pass the
> pixel t
On Tue, Oct 12, 2010 at 1:43 PM, James Robinson wrote:
> - Do we have the tools and infrastructure needed to do mass rebaselines in
> WebKit currently? We've built a number of tools to deal with the Chromium
> expectations, but since this has been a need unique to Chromium so far the
> tools only
To add a concrete data point, http://trac.webkit.org/changeset/69517 caused
a number of SVG tests to fail. It required 14 text rebaselines for Mac and
a further two more for Leopard (done by Adam Barth). In order to pass the
pixel tests in Chromium, it required 1506 new pixel baselines (checked i
Am 08.10.2010 um 20:14 schrieb Jeremy Orlow:
I'm not an expert on Pixel tests, but my understanding is that in
Chromium (where we've always run with tolerance 0) we've seen real
regressions that would have slipped by with something like tolerance
0.1. When you have 0 tolerance, it is more
I'm not an expert on Pixel tests, but my understanding is that in Chromium
(where we've always run with tolerance 0) we've seen real regressions that
would have slipped by with something like tolerance 0.1. When you have
0 tolerance, it is more maintenance work, but if we can avoid regressions,
it
> The problem I worry about is that on future Mac OS X releases, rendering of
> shapes may change in some tiny way that is not visible but enough to cause
> failures at tolerance 0. In the past, such false positives arose from time to
> time, which is one reason we added pixel test tolerance in
Am 08.10.2010 um 19:53 schrieb Maciej Stachowiak:
On Oct 8, 2010, at 12:46 AM, Nikolas Zimmermann wrote:
Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak:
On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote:
Good evening webkit folks,
I've finished landing svg/ pixel test baselines,
On Oct 8, 2010, at 12:46 AM, Nikolas Zimmermann wrote:
>
> Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak:
>
>>
>> On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote:
>>
>>> Good evening webkit folks,
>>>
>>> I've finished landing svg/ pixel test baselines, which pass with
>>> --toleran
Am 07.10.2010 um 22:28 schrieb Evan Martin:
Chromium also runs pixel tests (for all tests). For SVG, I recall we
have problems where 32-bit and 64-bit code will end up drawing
(antialiasing) curves differently. Does this sound familiar? Do you
have any suggestions on how to address it?
Thi
We missed many changes because of an existent tolerance level in the past. We
made a baseline for MacOS Leopard as well as Snow Leopard and I would active
pixel tests just for those two bots. I don't expect any problems. Niko and I
run pixel tests on different machines and get the same results.
Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak:
On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote:
Good evening webkit folks,
I've finished landing svg/ pixel test baselines, which pass with --
tolerance 0 on my 10.5 & 10.6 machines.
As the pixel testing is very important for the SVG
On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote:
> Good evening webkit folks,
>
> I've finished landing svg/ pixel test baselines, which pass with --tolerance
> 0 on my 10.5 & 10.6 machines.
> As the pixel testing is very important for the SVG tests, I'd like to run
> them on the bots, ex
This does seem like a great idea. The more pixel tests we can run on the
bots, the better!
J
On Thu, Oct 7, 2010 at 11:06 AM, Dirk Schulze wrote:
> I strongly support pixel tests for SVG on the bots! Niko and me are hard
> working to get SVG pxiel perfect at all time. We run pixel tests on eve
I strongly support pixel tests for SVG on the bots! Niko and me are hard
working to get SVG pxiel perfect at all time. We run pixel tests on every patch
we apply to the SVG code. And it would really help us if the bots blame any
change that causes a pixel test to fail, or at least give some kind
Good evening webkit folks,
I've finished landing svg/ pixel test baselines, which pass with --
tolerance 0 on my 10.5 & 10.6 machines.
As the pixel testing is very important for the SVG tests, I'd like to
run them on the bots, experimentally, so we can catch regressions
easily.
Maybe someo
18 matches
Mail list logo