Update SetPaintToLayer to accept LayerType

ui/views/animation/ink_drop.cc

 // Copyright 2016 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 "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);
 }
 
 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 {
   // Ensure the container View is found as the EventTarget instead of this.
   return false;
 }
 
 }  // namespace views