After enabling reftests for Direct 2D we are hitting this failure in this test suite.
The beveling at the two bottom corners of the border is slightly different. It's possible this is a bug in the test.
(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.
OS: Mac OS X → Windows 7
Version: unspecified → Trunk
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.)
(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.
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.
Looking at the images (on dholbert's machine), it looks like the edges are antialiased, which they shouldn't be with MODE_ALIASED.
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.
This is indeed caused by OPERATOR_ADD not working right. With proper support as being worked on in bug 580765 this is looking good.
Looks like this is fixed now.
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 :-).
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.
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.
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.
You need to log in before you can comment on or make changes to this bug.