Updates to overrides of InkDropHost::AddInkDropLayer()

chrome/browser/ui/views/bar_control_button.cc

Index: chrome/browser/ui/views/bar_control_button.cc
diff --git a/chrome/browser/ui/views/bar_control_button.cc b/chrome/browser/ui/views/bar_control_button.cc
index 0e4336d5533964aabfe476257ce75bcf48ac4f9f..e8c727c66dc22c4035a2795bba662a6849b70496 100644
--- a/chrome/browser/ui/views/bar_control_button.cc
+++ b/chrome/browser/ui/views/bar_control_button.cc
@@ -71,6 +71,8 @@ void BarControlButton::Layout() {
 }
 
 void BarControlButton::AddInkDropLayer(ui::Layer* ink_drop_layer) {
+  // TODO(estade|tdanderson): The ink drop layer should be positioned behind
+  //                          the button's image.

[tdanderson, 2015/11/18 16:14:17]

BarControlButton extends ImageButton, which does not have a child ImageView that
can be promoted to its own layer (as is done in ToolbarButton and
AppMenuButton). Is there a simple way to put the BarControlButton's SkImage into
its own layer for the duration of the ink drop animation without needing to have
a child ImageView? (And is BarControlButton even staying around for the long
term? I remember some talk about getting rid of it.)

[jonross, 2015/11/18 16:36:52]

We can follow the pattern used for CircleLayerDelegate::OnPaintLayer

https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/animation...

Create our own child layer for BarControlButton, and give it a LayerDelegate
that paints the SkImage

[Peter Kasting, 2015/11/18 21:04:53]

I recall proposing that we try to use it more widely and, if successful, rename
it something more general, but I don't know that anyone's suggested getting rid
of it.

[tdanderson, 2015/11/19 15:15:42]

Thanks for the suggestion; I will address this in a follow-up CL.

   SetPaintToLayer(true);
   SetFillsBoundsOpaquely(false);
   layer()->Add(ink_drop_layer);