Call blitFatAntiRect to avoid overhead in MaskAdditiveBlitter

This results in 25% (720ns vs 560ns) speedup for
path_fill_small_rect bench in 8888 config. Some skps have a lot of stroked
horizontal/vertical lines (e.g., bar charts) so this improvement could
have a great impact there. For example, cereal converts Microsoft word docx
to PNGs on server and the sample docx has a big bar chart. That inspired
this improvement.

Bug: skia:
Change-Id: Icf96c966edf87427b3d1f53da09a49930eda2ac1
Reviewed-on: https://skia-review.googlesource.com/46584
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>

1 files changed, 13 insertions, 5 deletions

diff --git a/src/core/SkScan_AAAPath.cpp b/src/core/SkScan_AAAPath.cpp
index e5478eaf69..ff6bf828f7 100644
--- a/src/core/SkScan_AAAPath.cpp
+++ b/src/core/SkScan_AAAPath.cpp
@@ -1676,29 +1676,37 @@ void SkScan::AAAFillPath(const SkPath& path, const SkRegion& origClip, SkBlitter
                          bool forceRLE) {
     FillPathFunc fillPathFunc = [](const SkPath& path, SkBlitter* blitter, bool isInverse,
             const SkIRect& ir, const SkRegion* clipRgn, const SkIRect* clipRect, bool forceRLE){
+        const SkIRect& clipBounds = clipRgn->getBounds();
+
         // The mask blitter (where we store intermediate alpha values directly in a mask, and then
         // call the real blitter once in the end to blit the whole mask) is faster than the RLE
         // blitter when the blit region is small enough (i.e., canHandleRect(ir)).
         // When isInverse is true, the blit region is no longer ir so we won't use the mask blitter.
         // The caller may also use the forceRLE flag to force not using the mask blitter.
+        // Also, when the path is a simple rect, preparing a mask and blitting it might have too
+        // much overhead. Hence we'll use blitFatAntiRect to avoid the mask and its overhead.
         if (MaskAdditiveBlitter::canHandleRect(ir) && !isInverse && !forceRLE) {
-            MaskAdditiveBlitter additiveBlitter(blitter, ir, *clipRgn, isInverse);
-            aaa_fill_path(path, clipRgn->getBounds(), &additiveBlitter, ir.fTop, ir.fBottom,
-                    clipRect == nullptr, true, forceRLE);
+            // blitFatAntiRect is slower than the normal AAA flow without MaskAdditiveBlitter.
+            // Hence only tryBlitFatAntiRect when MaskAdditiveBlitter would have been used.
+            if (!TryBlitFatAntiRect(blitter, path, clipBounds)) {
+                MaskAdditiveBlitter additiveBlitter(blitter, ir, *clipRgn, isInverse);
+                aaa_fill_path(path, clipBounds, &additiveBlitter, ir.fTop, ir.fBottom,
+                        clipRect == nullptr, true, forceRLE);
+            }
         } else if (!isInverse && path.isConvex()) {
             // If the filling area is convex (i.e., path.isConvex && !isInverse), our simpler
             // aaa_walk_convex_edges won't generate alphas above 255. Hence we don't need
             // SafeRLEAdditiveBlitter (which is slow due to clamping). The basic RLE blitter
             // RunBasedAdditiveBlitter would suffice.
             RunBasedAdditiveBlitter additiveBlitter(blitter, ir, *clipRgn, isInverse);
-            aaa_fill_path(path, clipRgn->getBounds(), &additiveBlitter, ir.fTop, ir.fBottom,
+            aaa_fill_path(path, clipBounds, &additiveBlitter, ir.fTop, ir.fBottom,
                     clipRect == nullptr, false, forceRLE);
         } else {
             // If the filling area might not be convex, the more involved aaa_walk_edges would
             // be called and we have to clamp the alpha downto 255. The SafeRLEAdditiveBlitter
             // does that at a cost of performance.
             SafeRLEAdditiveBlitter additiveBlitter(blitter, ir, *clipRgn, isInverse);
-            aaa_fill_path(path, clipRgn->getBounds(), &additiveBlitter, ir.fTop, ir.fBottom,
+            aaa_fill_path(path, clipBounds, &additiveBlitter, ir.fTop, ir.fBottom,
                     clipRect == nullptr, false, forceRLE);
         }
     };