Summary: | REGRESSION: rebaseline-chromium-webkit-tests uses non-zero tolerance for image dup detection | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Kent Tamura <tkent> | ||||||
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | abarth, dpranke, eric, hamaji, mihaip, tony | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Other | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Kent Tamura
2010-11-01 01:05:00 PDT
Created attachment 72493 [details]
Patch
Comment on attachment 72493 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=72493&action=review Sorry about the regression. > WebKitTools/Scripts/webkitpy/layout_tests/rebaseline_chromium_webkit_tests.py:881 > + options.tolerance = 0 Any reason why you wouldn't always set this? Before r70279, this tool was always setting tolerance to 0, which seems like the right thing to do. (In reply to comment #2) > > WebKitTools/Scripts/webkitpy/layout_tests/rebaseline_chromium_webkit_tests.py:881 > > + options.tolerance = 0 > > Any reason why you wouldn't always set this? Before r70279, this tool was always setting tolerance to 0, which seems like the right thing to do. Because It seems rebaseline-chromium-webkit-tests has code to support non-Chromium port targets. I don't know if it works. (In reply to comment #3) > Because It seems rebaseline-chromium-webkit-tests has code to support non-Chromium port targets. I don't know if it works. Ports that don't care about the tolerance setting will just ignore the field in the options object. new-run-webkit-tests always sets tolerance, it's up to each port to do something with it (only the Mac port respects it), and that hasn't been an issue. (In reply to comment #4) > (In reply to comment #3) > > Because It seems rebaseline-chromium-webkit-tests has code to support non-Chromium port targets. I don't know if it works. > > Ports that don't care about the tolerance setting will just ignore the field in the options object. new-run-webkit-tests always sets tolerance, it's up to each port to do something with it (only the Mac port respects it), and that hasn't been an issue. Ah, right. So, the ideal fix is that ImageDiff of the host port runs with the tolerance value of the target port? Good catch. I agree with Mihai that we should use a tolerance of 0 across the board. Meaning, I wouldn't even make it a command line option, just set it to zero in the call. Created attachment 72585 [details]
Patch 2 (always tolerance=0)
Would some review this please? (In reply to comment #9) > Would some review this please? someone Our goal here is to match the HTML5 spec. How does a WebKit nightly compare to Firefox 4 beta? wrong bug. :) Comment on attachment 72585 [details]
Patch 2 (always tolerance=0)
ok
Comment on attachment 72585 [details] Patch 2 (always tolerance=0) Clearing flags on attachment: 72585 Committed r71228: <http://trac.webkit.org/changeset/71228> All reviewed patches have been landed. Closing bug. |