Reinstate BoxPainter's unrederable background rrect logic

third_party/WebKit/Source/core/paint/BoxPainter.cpp

Index: third_party/WebKit/Source/core/paint/BoxPainter.cpp
diff --git a/third_party/WebKit/Source/core/paint/BoxPainter.cpp b/third_party/WebKit/Source/core/paint/BoxPainter.cpp
index 0eca8fd2c22a06c57d874abc0147cbd48ba66aec..b7e005a61ba2af7da17a4dfb21571ceabfc4df5e 100644
--- a/third_party/WebKit/Source/core/paint/BoxPainter.cpp
+++ b/third_party/WebKit/Source/core/paint/BoxPainter.cpp
@@ -421,9 +421,14 @@ inline bool paintFastBottomLayer(const LayoutBoxModelObject& obj, const PaintInf
     FloatRoundedRect border = info.isRoundedFill
         ? backgroundRoundedRectAdjustedForBleedAvoidance(obj, rect, bleedAvoidance, box, boxSize, info.includeLeftEdge, info.includeRightEdge)
         : FloatRoundedRect(pixelSnappedIntRect(rect));
-    // We only take this path for BorderFillBox. https://www.w3.org/TR/css3-background/#corner-overlap
-    // should ensure that the border rrect is renderable.
-    DCHECK(border.isRenderable());
+
+    Optional<RoundedInnerRectClipper> clipper;
+    if (info.isRoundedFill && !border.isRenderable()) {

[chrishtr, 2016/06/30 00:48:14]

Why not ensure the border is renderable at the time it's inset? That is the
place where the business logic has best opportunity
to do the right thing, rather than falling back to non-rounded in catchall logic
later. Maybe the inset logic should choose the largest value it can while still
being renderable for instance?

[f(malita), 2016/06/30 13:53:38]

Yeah, that was my first thought also, but it turns out we do want the
"unrenderable" version in these cases.

It mostly comes into play when computing the inner border shape, and there is
only one correct answer: the inner shape is parallel to the outer shape, inset
by border width.

If we tweak the logic to only inset by the max value which maintains the
renderable invariant, we may not inset enough - e.g. if one radius is 100%, it
leaves no room for insetting at all => our inner edge == outer edge, which is
incorrect.

Another option is to "borrow" the inset from the other radius when needed - e.g.
if top radius is 0 and bottom radius is 100% and we attempt to inset by 5, we
subtract 10 from the bottom radius only (can't reduce top at all).  But this
means our bottom radius is now smaller than it should be, which again yields
incorrect results (inner edge no longer parallel to outer edge).  E.g. we end up
with something like this http://i.imgur.com/4VIu0Sf.png instead of
http://i.imgur.com/sKWw01U.png.

So yeah, the correct geometry is "unrenderable", according to the
FloatRoundedRect definition.  Which doesn't mean we cannot render it, but that
we must use more convoluted logic rather than a single drawRRect call.

+        // When the rrect is not renderable, we resort to clipping.
+        // RoundedInnerRectClipper handles this case via discrete, corner-wise clipping.
+        clipper.emplace(obj, paintInfo, rect, border, ApplyToContext);
+        border.setRadii(FloatRoundedRect::Radii());
+    }
 
     // Paint the color + shadow if needed.
     if (info.shouldPaintColor) {