Update SetPaintToLayer to accept LayerType

ui/views/animation/ink_drop.cc

Index: ui/views/animation/ink_drop.cc
diff --git a/ui/views/animation/ink_drop.cc b/ui/views/animation/ink_drop.cc
index a82f4c51b5b78c653a9e49e63e934d9b5f590c22..f48948d2294291da69ef160e6d487ae2371108e1 100644
--- a/ui/views/animation/ink_drop.cc
+++ b/ui/views/animation/ink_drop.cc
@@ -4,12 +4,14 @@
 
 #include "ui/views/animation/ink_drop.h"
 
+#include "ui/compositor/layer_type.h"
+
 namespace views {
 
 InkDropContainerView::InkDropContainerView() {}
 
 void InkDropContainerView::AddInkDropLayer(ui::Layer* ink_drop_layer) {
-  SetPaintToLayer(true);
+  SetPaintToLayer(ui::LAYER_TEXTURED);

[bruthig, 2017/01/20 20:14:18]

nit: This may not need to be a textured layer.  A ui::LAYER_NOT_DRAWN should be
sufficient.  Assuming child Views will correctly paint to a textured layer owned
by an ancestor of this.

It would be preferable from an InkDrop standpoint for the API to allow Views to
have a LAYER_NOT_DRAWN Layer but I'm not sure if there are potential issues with
that (e.g. painting).

Sadrul, any insight?

[sadrul, 2017/01/20 20:32:52]

I think for cases like this, we can probably do a SOLID_COLOR with color ==
transparent? I think that's better than the alternative (SetPaintLayer(bool,
layer-type)).

But ...
What does this mean? Child views of InkDropContainerView (IDCV) should paint in
their own layers, or in the layer of IDCV. They should not pain in IDCV's
ancestor view's layer.

   SetVisible(true);
   layer()->SetFillsBoundsOpaquely(false);
   layer()->Add(ink_drop_layer);
@@ -18,7 +20,7 @@ void InkDropContainerView::AddInkDropLayer(ui::Layer* ink_drop_layer) {
 void InkDropContainerView::RemoveInkDropLayer(ui::Layer* ink_drop_layer) {
   layer()->Remove(ink_drop_layer);
   SetVisible(false);
-  SetPaintToLayer(false);
+  SetPaintToLayer(ui::LAYER_NOT_DRAWN);
 }
 
 bool InkDropContainerView::CanProcessEventsWithinSubtree() const {