Bug 94746 - decide what (and how) we should set the tolerance for ref test pixel compares and test for that
Summary: decide what (and how) we should set the tolerance for ref test pixel compares...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dirk Pranke
URL:
Keywords: NRWT
Depends on:
Blocks:
 
Reported: 2012-08-22 13:47 PDT by Dirk Pranke
Modified: 2012-08-30 13:22 PDT (History)
8 users (show)

See Also:


Attachments
Patch (1.53 KB, patch)
2012-08-30 12:35 PDT, Dirk Pranke
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Pranke 2012-08-22 13:47:39 PDT
See comments in https://bugs.webkit.org/show_bug.cgi?id=94704 for background ... it's perhaps not clear if we should use the default tolerance the port specifies for pixel tests also for ref tests, or if ref tests should always require an exact match (tolerance == 0 or just hash compares), or if we should have a separate default-tolerance-for-ref-tests parameter.

Once we agree on this, we should make sure this is implemented and write a test to check the behavior (we don't have a test today).
Comment 1 Ojan Vafai 2012-08-22 13:52:48 PDT
I don't see why we'd ever want a tolerance other than 0 for reftests. The point of tolerance is to handle things like different text anti-aliasing across OS releases. None of these sort of things apply to reftests.
Comment 2 Ryosuke Niwa 2012-08-22 14:00:58 PDT
Yeah, it seems like we shouldn't need any tolerance for ref tests.
Comment 3 Dirk Pranke 2012-08-22 14:15:46 PDT
I don't have any real argument against using 0. Simon, anyone else from Apple, any objections?
Comment 4 Simon Fraser (smfr) 2012-08-22 14:56:48 PDT
No objection, but I wouldn't be surprised if some ref tests are "close but not exact" and fail with a zero tolerance. We'll have to try it and see.
Comment 5 Ryosuke Niwa 2012-08-22 14:59:27 PDT
I guess 1px rounding differences are common (e.g. inline-block vs. inline) in text rendering.
Comment 6 Dirk Pranke 2012-08-22 15:00:48 PDT
it would seem a bit odd to me to have reftests that attempt to render the same string of text two different ways and hope that they would be the same, but maybe I'm not being creative enough. Do we have many of those?
Comment 7 Ryosuke Niwa 2012-08-22 15:03:32 PDT
(In reply to comment #6)
> it would seem a bit odd to me to have reftests that attempt to render the same string of text two different ways and hope that they would be the same, but maybe I'm not being creative enough. Do we have many of those?

I've hit that when I was converting a test for bdi because inline-block and inline have a different semantics in UBA.
Comment 8 Dirk Pranke 2012-08-30 12:35:04 PDT
Created attachment 161534 [details]
Patch
Comment 9 Dirk Pranke 2012-08-30 12:35:32 PDT
Looks like there's general consensus that we should require exact matches. I'm adding an assertion to the test cases to enforce this.
Comment 10 WebKit Review Bot 2012-08-30 13:22:13 PDT
Comment on attachment 161534 [details]
Patch

Clearing flags on attachment: 161534

Committed r127180: <http://trac.webkit.org/changeset/127180>
Comment 11 WebKit Review Bot 2012-08-30 13:22:17 PDT
All reviewed patches have been landed.  Closing bug.