1841349 - WPT css/css-transforms/skew-test1.html fails in Firefox, with antialiasing fuzziness along edge of transformed shape

Status: RESOLVED MOVED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

We fail this interop-2023-relevant test:
https://wpt.fyi/results/css/css-transforms/skew-test1.html?label=master&label=experimental&aligned
Testcase/reference:
http://wpt.live/css/css-transforms/skew-test1.html
http://wpt.live/css/css-transforms/reference/skew-test1-ref.html

Looking at the test-failure-comparison, it seems mostly like just annotatable fuzziness, though it's quite a lot:

maxDifference: 255
totalPixels: 878 

The maxDifference:255 is from a single pixel near the top left corner of the shape that's red in the testcase vs. lime in the reference case (255 in the red channel vs. 255 in the green channel). (This is super weird since that red pixel seems to be surrounded by lime pixels... I also don't see that red pixel when I view the testcase locally.)

The large "totalPixels" is from antialiasing differences along the edge of the shape. It looks like the shape in the testcase is ~1px larger than the reference case on all sides, or something like that.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: the part of the test snapshot with the red pixel, scaled up 10x for convenience

The maxDifference:255 is from a single pixel near the top left corner of the shape that's red in the testcase vs. lime in the reference case (255 in the red channel vs. 255 in the green channel). (This is super weird since that red pixel seems to be surrounded by lime pixels... I also don't see that red pixel when I view the testcase locally.)

Here's a cropped portion of the testcase-snapshot (from the WPT harness), showing the single red pixel. I've scaled it up 10x (in a pixellated way) to make it easier to see.

Comment 2

[Daniel Holbert [:dholbert]]

Aha, two other interesting things:
(1) The reference case has extremely magical/"tuned" fractional values in its polygon:
<polygon points="0,0 150,54.595535 236.602540,204.595535 86.602540,150" style="fill:lime"></polygon>
It's not surprising that there's a little bit of fuzz from matching a transformed div against that.

(2) The testcase already has a fuzzy annotation that's nearly sufficient (presumably because this is similarly-fuzzy in other browsers):

<meta name="fuzzy" content="maxDifference=17-233;totalPixels=90-858">

So: quite reasonable to bump the upper edge of both ranges a little to accomodate our observed fuzziness.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: Bug 1841349 part 1: Slightly increase the fuzzy tolerance in skew-test1.html to match observed levels in Firefox. r?#layout-reviewers

Note: these fuzzy tolerance values are high, but they already were quite high
before this commit; this is just increasing them slightly.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

(This is super weird since that red pixel seems to be surrounded by lime pixels... I also don't see that red pixel when I view the testcase locally.)

I filed bug 1841355 to track that issue (since I'm using this issue here to land a fuzzy annotation). I'll also land a patch here to add a reftest with this single red pixel shining through, to help us validate that bug 1841355 is real & persists (and help us detect if it gets fixed by changes elsewhere).

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: Bug 1841349: Add a reftest with variant of WPT with strict expected-fuzzy annotation, so we can detect if our behavior changes.

This reftest is to demonstrate (and test for behavior-changes around) a
followup bug: bug 1841355.

Depends on D182605

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: Reworked version of skew-test1.html

Comment 7

[Daniel Holbert [:dholbert]]

I posted https://github.com/web-platform-tests/wpt/pull/40953 with a reworked version of the test that doesn't require a fuzzy tolerance. I also filed https://github.com/web-platform-tests/interop/issues/378 to follow the formal interop-2023 process for the test-change.

See just-attached file for the actual reworked test itself.

Comment 8

[Daniel Holbert [:dholbert]]

I fixed this upstream in https://github.com/web-platform-tests/wpt/pull/40961 (just merged).

Resolving as MOVED to that PR.

I'll do one more try run just to be sure the new reftest in https://phabricator.services.mozilla.com/D182627 is still correctly-annotated, and I'll land that as a followup if Try looks good.

Comment 9

[Daniel Holbert [:dholbert]]

Try run for adding the new reftest: https://treeherder.mozilla.org/jobs?repo=try&revision=21bebd4a62ab868b267422491213e74c034b3e94

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/409794f954d9
Add a reftest with variant of WPT with strict expected-fuzzy annotation, so we can detect if our behavior changes. r=emilio

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/409794f954d9