cros: Fix browser header wrongly drawn frame image

chrome/browser/ui/views/frame/browser_header_painter_ash.cc

Index: chrome/browser/ui/views/frame/browser_header_painter_ash.cc
diff --git a/chrome/browser/ui/views/frame/browser_header_painter_ash.cc b/chrome/browser/ui/views/frame/browser_header_painter_ash.cc
index eeb0c98f6a2f829d7ca245441054a7aae4e586f5..d3ff4547595b0e84541fb4bd30f7475deb5dddb0 100644
--- a/chrome/browser/ui/views/frame/browser_header_painter_ash.cc
+++ b/chrome/browser/ui/views/frame/browser_header_painter_ash.cc
@@ -81,7 +81,8 @@ void PaintFrameImagesInRoundRect(gfx::Canvas* canvas,
     canvas->DrawRect(bounds, flags);
   } else if (frame_overlay_image.isNull()) {
     flags.setAlpha(alpha);
-    canvas->DrawImageInt(frame_image, -image_inset_x, 0, flags);
+    canvas->TileImageInt(frame_image, image_inset_x, 0, 0, 0, bounds.width(),

[danakj, 2017/03/24 16:29:30]

pkasting should confirm the -inset to +inset is right.. but LGTM in spirit.

[Peter Kasting, 2017/03/24 20:08:12]

The coord change is fine (changes from dest to source coords), but the
functionality isn't: TileImageInt() doesn't take a flags arg, which is why we
had to SaveLayer in the other arm to begin with.

Either we can go back to the simpler code, or we can try to work around this,
maybe by manually implementing the tile call here, or by mucking with the canvas
APIs.

Unless we know that SaveLayer is really costly and this has a measurable perf or
battery effect, my preference would be the former.

[danakj, 2017/03/24 20:22:52]

Oh oops. Using the underlying PaintCanvas directly would be fine (that's where
we're trying to head anyway).
save layer is similar to what this did before, it draws to an intermediate
target then draws that to the primary target. So it requires extra memory
bandwidth, and possible allocations if not using a cached memory chunk.

I suggest we add PaintFlags to (an override of?) TileImageInt. In
Canvas::TileImageInt we use that and add the shader to it. The setBlendMode
should be removed (it's the default blend mode anyway so that's a no-op)
https://cs.chromium.org/chromium/src/ui/gfx/canvas.cc?rcl=a2d5d8259ad5462f1df...

[Peter Kasting, 2017/03/24 20:26:38]

If TileImageInt() got a with-flags variant, and DrawImageInt already has one,
then the only thing in the else arm that doesn't have one is DrawColor.  Can we
easily rewrite that to some similar call that uses flags?  If so, we can avoid
introducing a third conditional arm here AND eliminate the existing SaveLayer
call.

[danakj, 2017/03/24 20:33:54]

I thought you need the SaveLayer to draw the contents of the whole layer with
kPlus blend mode together, instead of each piece as kPlus on top of the other.

[Peter Kasting, 2017/03/24 20:39:40]

Oh.  Yeah, that's probably correct.  Argh.

I still worry that we're micro-optimizing something that maybe doesn't matter. 
But definitely don't micro-optimize by doing it the way I suggested.  :P

[danakj, 2017/03/24 20:40:50]

Memory allocs/bandwidth are one of the best things to optimize and will easily
dominate the time spent in raster. We should definitely not savelayer
carelessly.

+                         bounds.height());
   } else {
     flags.setAlpha(alpha);
     canvas->SaveLayerWithFlags(flags);