Reinstate BoxPainter's unrederable background rrect logic

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

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "core/paint/BoxPainter.h"
 
 #include "core/HTMLNames.h"
 #include "core/frame/Settings.h"
 #include "core/html/HTMLFrameOwnerElement.h"
 #include "core/layout/ImageQualityController.h"
@@ skipping 403 matching lines @@
                 return false;
         }
     }
 
     // At this point we're committed to the fast path: the destination (r)rect fits within a single
     // tile, and we can paint it using direct draw(R)Rect() calls.
     GraphicsContext& context = paintInfo.context;
     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) {
         const ShadowContext shadowContext(context, obj, info.shouldPaintShadow);
         context.fillRoundedRect(border, info.color);
     }
 
     // Paint the image + shadow if needed.
     if (!info.shouldPaintImage || imageTile.isEmpty())
         return true;
@@ skipping 378 matching lines @@
     }
 }
 
 bool BoxPainter::shouldForceWhiteBackgroundForPrintEconomy(const ComputedStyle& style, const Document& document)
 {
     return document.printing() && style.getPrintColorAdjust() == PrintColorAdjustEconomy
         && (!document.settings() || !document.settings()->shouldPrintBackgrounds());
 }
 
 } // namespace blink