Fix bug where ovals' AA exceed bounds by .5 pixel

src/gpu/GrOvalRenderer.cpp

 /*
  * Copyright 2013 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #include "GrOvalRenderer.h"
 
 #include "GrBatchFlushState.h"
@@ skipping 920 matching lines @@
         // this is legit only if scale & translation (which should be the case at the moment)
         if (isStrokeOnly) {
             innerXRadius = xRadius - scaledStroke.fX;
             innerYRadius = yRadius - scaledStroke.fY;
         }
 
         xRadius += scaledStroke.fX;
         yRadius += scaledStroke.fY;
     }
 
-    // We've extended the outer x radius out half a pixel to antialias.
-    // This will also expand the rect so all the pixels will be captured.
-    // TODO: Consider if we should use sqrt(2)/2 instead
-    xRadius += SK_ScalarHalf;
-    yRadius += SK_ScalarHalf;

[jvanverth1, 2016/06/30 15:29:19]

I don't think this is quite right. We need to expand the bounds by 0.5 in each
direction (left, top, right, bottom) to make space for 1/2 a pixel on each side
of anti-aliasing. Otherwise we'll chop off that 1/2 a pixel. I think what needs
to happen is:

1) Leave the inner and outer radii alone. Those are used for the ellipse
function so they should stay the original size of the ellipse.
2) When creating the devBounds, expand it by 0.5 in all directions (you can do
that with SkRect::outset).
3) Up in EllipseBatch::onPrepareDraws, adjust fOffset so it's 0.5 bigger in each
direction than (xRadius, yRadius).

See lines 1664 and 1454-1470 to see how this is handled with roundrects.

[vjiaoblack, 2016/06/30 16:55:35]

I've implemented these changes locally, and cross-compared the results between
the original (before this series of changes entirely) and new (your proposed
changes) versions of the code, along with switching between the diellipse code
and the ellipse code.

Since the problem originally seemed to be that the GPU-drawn oval was slightly
too large, esp noticeably with the hairline ovals (or have I interpreted the bug
wrong? I thought it was clear, but I indeed could have misinterpreted it), this
current fix does not appear to resolve that problem itself.

Actually, (I think due to increasing the fOffset) the hairline ovals became
slightly thicker and larger.

Are you sure this is the intended fix?

I looked at the GM:rrect test, and admittedly, the rounded rects look pretty
spot on.

-
     EllipseBatch::Geometry geometry;
     geometry.fColor = color;
     geometry.fXRadius = xRadius;
     geometry.fYRadius = yRadius;
     geometry.fInnerXRadius = innerXRadius;
     geometry.fInnerYRadius = innerYRadius;
     geometry.fDevBounds = SkRect::MakeLTRB(center.fX - xRadius, center.fY - yRadius,
                                            center.fX + xRadius, center.fY + yRadius);
 
     return new EllipseBatch(geometry, viewMatrix,
@@ skipping 760 matching lines @@
 }
 
 DRAW_BATCH_TEST_DEFINE(RRectBatch) {
     SkMatrix viewMatrix = GrTest::TestMatrixRectStaysRect(random);
     GrColor color = GrRandomColor(random);
     const SkRRect& rrect = GrTest::TestRRectSimple(random);
     return create_rrect_batch(color, viewMatrix, rrect, GrTest::TestStrokeRec(random));
 }
 
 #endif