578116 - REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/379349-1b.xhtml 379349-1c.xhtml

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Armen [:armenzg]]

Attachment: log

After enabling reftests for Direct 2D we are hitting this failure in this test suite.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The beveling at the two bottom corners of the border is slightly different.  It's possible this is a bug in the test.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to comment #1)
> The beveling at the two bottom corners of the border is slightly different

Specifically, there are some hints of red, in the testcase versions. (and no red in the reference version)

From glancing at the test source, it looks like the blue border-bottom is expected to entirely cover up a red border-bottom behind it.  But with Direct2D, we're apparently averaging in some redness at the beveled edge.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Maybe the d2d backend isn't honoring the
  ctx->SetAntialiasMode(gfxContext::MODE_ALIASED);
call in the border-drawing code.  Or perhaps something wrong with handling:
        mContext->SetOperator(gfxContext::OPERATOR_ADD);
?

(I didn't see the red in the images, but I didn't look that closely; they just looked like they were at slightly different positions to me.)

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to comment #3)
> Maybe the d2d backend isn't honoring the
>   ctx->SetAntialiasMode(gfxContext::MODE_ALIASED);
> call in the border-drawing code.  Or perhaps something wrong with handling:
>         mContext->SetOperator(gfxContext::OPERATOR_ADD);
> ?
> 
> (I didn't see the red in the images, but I didn't look that closely; they just
> looked like they were at slightly different positions to me.)

MODE_ALIASED is handled correctly.

OPERATOR_ADD -should- trigger the cairo-fallback path.

Comment 5

[Bas Schouten (:bas.schouten)]

Ah, so for stroke the OPERATOR_ADD doesn't fallback and it does an OVER instead because otherwise we'd be doing a lot of fallback for border drawing. This causes slightly incorrect behavior, it's in the comment of the code actually, we need to see what we do about that.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looking at the images (on dholbert's machine), it looks like the edges are antialiased, which they shouldn't be with MODE_ALIASED.

Comment 7

[Daniel Holbert [:dholbert]]

Yup -- the left & right edges look antialiased on both the reference case and testcase. The testcases have shades of red in these edge-regions, whereas the reference cases only have shades of blue there.

Comment 8

[Bas Schouten (:bas.schouten)]

This is indeed caused by OPERATOR_ADD not working right. With proper support as being worked on in bug 580765 this is looking good.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looks like this is fixed now.

Comment 10

[Bas Schouten (:bas.schouten)]

This wasn't actually fixed. OPERATOR_ADD did fix this in the sense that there's no longer any shades of red. However apparently some pixels are still different, according to the analyzer around the same location. I suspect these are rounding errors from the different coverage calculations, but I'm trying to find them still :-).

Comment 11

[Bas Schouten (:bas.schouten)]

So at the bottom most pixels at the antialiased edges there's still a wee bit of red shining through, 50,40,232 in the test and 50,50,232 in the reference. I'm not sure what the cause of this is. As I don't really understand what the code here does. Other than the slight red still in there that the test case looks almost the same as the test case on 3.6.8, except that has slightly different coverage values for the pixels.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

By "this", I meant that I thought the border-related failures were fixed (which was that I thought this particular bug covered).  I thought it looked like the border-related failures were fixed, but there were still a bunch of text-related failures, all intermittent, but intermittent at high frequencies.

Comment 13

[Bas Schouten (:bas.schouten)]

So, what I suspect is happening here, is that the edge of the left/right borders and the bottom one are inconsistently antialiased. i.e. the 50% coverage pixel on one border and the 50% coverage pixel on the other one don't add up to 255 alpha. What then happens is a little bit of whatever is behind there that is apparently red is showing through. Some AA inconsistencies in D2D would be no surprise, I've yet to gather evidence of this theory though.

Comment 14

[Intermittent Failures Robot]

1 failures in 4637 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform breakdown:

• android-hw-p2-8-0-arm7-api-16-qr: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=578116&startday=2019-09-09&endday=2019-09-15&tree=all