cc: Main thread skip single layers instead of subtrees

cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use the iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/0f10629e6702683168b2ce68fa2e50d2a5594f25
Cr-Commit-Position: refs/heads/master@{#386083}

[sunxd, 2016-04-06 18:07:09]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees (NOT FOR REVIEW)

BUG=600509
==========

to

==========
cc: Main thread skip single layers instead of subtrees (NOT FOR REVIEW)

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[sunxd, 2016-04-06 18:48:41]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees (NOT FOR REVIEW)

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Main thread skip single layers instead of subtrees

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[sunxd, 2016-04-06 18:48:41]

sunxd@chromium.org changed reviewers:
+ ajuma@chromium.org, jaydasika@chromium.org, vollick@chromium.org

[sunxd, 2016-04-06 18:48:48]

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:456:
!effect_node->data.to_screen_opacity_can_animate_on_impl;
I'm also considering merging the logic of main/impl, this is one of the
differences.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:513: root_layer->layer_tree_host(),
I'm also considering merging the logic of main/impl, this is one of the
differences.

[Ian Vollick, 2016-04-06 19:42:27]

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:419: const EffectTree& effect_tree =
transform_tree.property_trees()->effect_tree;
nit: I'd just pass this in since you have it handy in the outer scope.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:426: transform_node->data.to_screen_is_animated;
This isn't worth doing anything about in this CL, but I wonder if is_animated is
misleading. Looking at the property tree builder, I see that it does get set to
true if we have a potentially running animation, but it's not obvious to me that
to_screen_is_animated is true for potential animations, too.

to_screen_is_potentially_animated is quite a mouthful, though. wdyt?

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:456:
!effect_node->data.to_screen_opacity_can_animate_on_impl;
On 2016/04/06 18:48:48, sunxd wrote:
> I'm also considering merging the logic of main/impl, this is one of the
> differences.

It would be fantastic if you could do this. This seems like a difficult
spot-the-differences game at the moment.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:530: // don't need to be updated.
nit: wrapping issues.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host_common.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host_common.h:217: const CallFunctionLayerType& type) {
This CallFunctionForLayer stuff seems reasonable (it's what we have today), but
if we had an iterator, couldn't we use std::for_each with an early out? (I don't
feel strongly about this).

[ajuma, 2016-04-06 19:49:29]

Please also expand the description to say why we're making this change.

https://codereview.chromium.org/1864183002/diff/20001/cc/layers/layer_impl.h
File cc/layers/layer_impl.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/layers/layer_impl.h#...
cc/layers/layer_impl.h:101: bool OpacityCanAnimateOnImplThread() const { return
false; }
Hmm. This sounds confusing (since opacity can indeed animated on the impl thread
for some layers), and I think it can be removed (see comment in
property_tree_builder.cc).

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.h:64: void CC_EXPORT
FindLayersThatNeedUpdates(Layer* root_layer,
This should take a LayerTreeHost instead of a Layer.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/property_tree_...
File cc/trees/property_tree_builder.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/property_tree_...
cc/trees/property_tree_builder.cc:637: layer->OpacityCanAnimateOnImplThread();
I believe to_screen_opacity_is_animated already accounts for this, so this
shouldn't be needed (see the definition of IsAnimatingOpacity, which is used to
compute has_animated_opacity).

[sunxd, 2016-04-07 15:37:13]

https://codereview.chromium.org/1864183002/diff/20001/cc/layers/layer_impl.h
File cc/layers/layer_impl.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/layers/layer_impl.h#...
cc/layers/layer_impl.h:101: bool OpacityCanAnimateOnImplThread() const { return
false; }
On 2016/04/06 19:49:28, ajuma wrote:
> Hmm. This sounds confusing (since opacity can indeed animated on the impl
thread
> for some layers), and I think it can be removed (see comment in
> property_tree_builder.cc).

Done.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:419: const EffectTree& effect_tree =
transform_tree.property_trees()->effect_tree;
On 2016/04/06 19:42:26, vollick wrote:
> nit: I'd just pass this in since you have it handy in the outer scope.

Done.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:426: transform_node->data.to_screen_is_animated;
On 2016/04/06 19:42:26, vollick wrote:
> This isn't worth doing anything about in this CL, but I wonder if is_animated
is
> misleading. Looking at the property tree builder, I see that it does get set
to
> true if we have a potentially running animation, but it's not obvious to me
that
> to_screen_is_animated is true for potential animations, too.
> 
> to_screen_is_potentially_animated is quite a mouthful, though. wdyt?

I think so. When updating animation properties, to_screen_is_animated is set to
be node->data.is_animated || parent_node->Data.to_screen_is_animated. So I guess
we can change that to "potentially animated". And probably we can change
is_animated to clarify the meaning in the future.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:456:
!effect_node->data.to_screen_opacity_can_animate_on_impl;
On 2016/04/06 19:42:26, vollick wrote:
> On 2016/04/06 18:48:48, sunxd wrote:
> > I'm also considering merging the logic of main/impl, this is one of the
> > differences.
> 
> It would be fantastic if you could do this. This seems like a difficult
> spot-the-differences game at the moment.

Yes, jaydasika@ is going to work on simplifying the skipping logic, I think
after his change it would be easier to merge the two paths together.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:530: // don't need to be updated.
On 2016/04/06 19:42:26, vollick wrote:
> nit: wrapping issues.

Done.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.h:64: void CC_EXPORT
FindLayersThatNeedUpdates(Layer* root_layer,
On 2016/04/06 19:49:28, ajuma wrote:
> This should take a LayerTreeHost instead of a Layer.

Done.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host_common.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host_common.h:217: const CallFunctionLayerType& type) {
On 2016/04/06 19:42:26, vollick wrote:
> This CallFunctionForLayer stuff seems reasonable (it's what we have today),
but
> if we had an iterator, couldn't we use std::for_each with an early out? (I
don't
> feel strongly about this).

I think we can, but at some time when layer list is behind the flag, we still
have to support tree structure, this function can be a wrapper: for Layer it
uses tree hierarchy, for LayerImpl it uses for_each (line 258).

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/property_tree_...
File cc/trees/property_tree_builder.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/property_tree_...
cc/trees/property_tree_builder.cc:637: layer->OpacityCanAnimateOnImplThread();
On 2016/04/06 19:49:29, ajuma wrote:
> I believe to_screen_opacity_is_animated already accounts for this, so this
> shouldn't be needed (see the definition of IsAnimatingOpacity, which is used
to
> compute has_animated_opacity).

Done.

[Ian Vollick, 2016-04-07 17:18:15]

The CQ bit was checked by vollick@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-07 17:18:33]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1864183002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1864183002/60001

[Ian Vollick, 2016-04-07 17:20:25]

The skipping logic lgtm % ajuma.

I still think we should get rid of CallFunctionForEveryLayer, but I'd be happy
with doing that in a follow up patch.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:456:
!effect_node->data.to_screen_opacity_can_animate_on_impl;
On 2016/04/07 15:37:12, sunxd wrote:
> On 2016/04/06 19:42:26, vollick wrote:
> > On 2016/04/06 18:48:48, sunxd wrote:
> > > I'm also considering merging the logic of main/impl, this is one of the
> > > differences.
> > 
> > It would be fantastic if you could do this. This seems like a difficult
> > spot-the-differences game at the moment.
> 
> Yes, jaydasika@ is going to work on simplifying the skipping logic, I think
> after his change it would be easier to merge the two paths together.

kk. makes sense.

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host_common.h (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host_common.h:217: const CallFunctionLayerType& type) {
On 2016/04/07 15:37:13, sunxd wrote:
> On 2016/04/06 19:42:26, vollick wrote:
> > This CallFunctionForLayer stuff seems reasonable (it's what we have today),
> but
> > if we had an iterator, couldn't we use std::for_each with an early out? (I
> don't
> > feel strongly about this).
> 
> I think we can, but at some time when layer list is behind the flag, we still
> have to support tree structure, this function can be a wrapper: for Layer it
> uses tree hierarchy, for LayerImpl it uses for_each (line 258).

Well, the iterator is meant to be the wrapper that hides the actual
layer/layerimpl data structure.

Say we wrote a cc::Layer iterator and updated LayerTreeHost in the same way that
we updated LayerTreeImpl. (We'd also have to teach the iterator to visit mask
and replica layers).

Every call to CallFunctionForEveryLayer(LayerTreeImpl* lti, const Function& f)
could be replaced with

for (auto* layer : *host_impl)
  f(layer);

And the LayerTreeHost analog would look about the same

for (auto* layer : *host)
  f(layer);

And we wouldn't always need a function f, we could just do the work on layer in
the body of the for loop. Bottom line: once we have iterators
CallFunctionForEveryLayer isn't as useful a utility function as it once was.

This would mean updating all the call sites, but you're doing that anyhow by
adding the type param, so the churn should be similar.

[sunxd, 2016-04-07 18:07:41]

On 2016/04/07 17:20:25, vollick wrote:
> The skipping logic lgtm % ajuma.
> 
> I still think we should get rid of CallFunctionForEveryLayer, but I'd be happy
> with doing that in a follow up patch.
> 
>
https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
> File cc/trees/draw_property_utils.cc (right):
> 
>
https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
> cc/trees/draw_property_utils.cc:456:
> !effect_node->data.to_screen_opacity_can_animate_on_impl;
> On 2016/04/07 15:37:12, sunxd wrote:
> > On 2016/04/06 19:42:26, vollick wrote:
> > > On 2016/04/06 18:48:48, sunxd wrote:
> > > > I'm also considering merging the logic of main/impl, this is one of the
> > > > differences.
> > > 
> > > It would be fantastic if you could do this. This seems like a difficult
> > > spot-the-differences game at the moment.
> > 
> > Yes, jaydasika@ is going to work on simplifying the skipping logic, I think
> > after his change it would be easier to merge the two paths together.
> 
> kk. makes sense.
> 
>
https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
> File cc/trees/layer_tree_host_common.h (right):
> 
>
https://codereview.chromium.org/1864183002/diff/20001/cc/trees/layer_tree_hos...
> cc/trees/layer_tree_host_common.h:217: const CallFunctionLayerType& type) {
> On 2016/04/07 15:37:13, sunxd wrote:
> > On 2016/04/06 19:42:26, vollick wrote:
> > > This CallFunctionForLayer stuff seems reasonable (it's what we have
today),
> > but
> > > if we had an iterator, couldn't we use std::for_each with an early out? (I
> > don't
> > > feel strongly about this).
> > 
> > I think we can, but at some time when layer list is behind the flag, we
still
> > have to support tree structure, this function can be a wrapper: for Layer it
> > uses tree hierarchy, for LayerImpl it uses for_each (line 258).
> 
> Well, the iterator is meant to be the wrapper that hides the actual
> layer/layerimpl data structure.
> 
> Say we wrote a cc::Layer iterator and updated LayerTreeHost in the same way
that
> we updated LayerTreeImpl. (We'd also have to teach the iterator to visit mask
> and replica layers).
> 
> Every call to CallFunctionForEveryLayer(LayerTreeImpl* lti, const Function& f)
> could be replaced with
> 
> for (auto* layer : *host_impl)
>   f(layer);
> 
> And the LayerTreeHost analog would look about the same
> 
> for (auto* layer : *host)
>   f(layer);
> 
> And we wouldn't always need a function f, we could just do the work on layer
in
> the body of the for loop. Bottom line: once we have iterators
> CallFunctionForEveryLayer isn't as useful a utility function as it once was.
> 
> This would mean updating all the call sites, but you're doing that anyhow by
> adding the type param, so the churn should be similar.

Agreed, but I think this change needs to happen after we get a layer list on
main
thread. I will file a bug to track this.

[commit-bot: I haz the power, 2016-04-07 18:24:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-07 18:24:31]

Dry run: This issue passed the CQ dry run.

[ajuma, 2016-04-07 18:46:47]

lgtm

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1864183002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:530: // don't need to be updated.
On 2016/04/07 15:37:13, sunxd wrote:
> On 2016/04/06 19:42:26, vollick wrote:
> > nit: wrapping issues.
> 
> Done.

The wrapping of the comment still needs fixing.

https://codereview.chromium.org/1864183002/diff/60001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1864183002/diff/60001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:456: //!
effect_node->data.to_screen_opacity_can_animate_on_impl;
Nit: this line should be deleted

[sunxd, 2016-04-07 18:55:36]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror of issue 1811423002 on the main thread. After
getting rid of tree hierarchy in LayerTreeHost, we won't be
able to skip subtrees, instead we skip every single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[sunxd, 2016-04-07 18:56:46]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror of issue 1811423002 on the main thread. After
getting rid of tree hierarchy in LayerTreeHost, we won't be
able to skip subtrees, instead we skip every single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main 
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[sunxd, 2016-04-07 18:56:52]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main 
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main 
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use the iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[sunxd, 2016-04-07 19:03:45]

The CQ bit was checked by sunxd@chromium.org

[sunxd, 2016-04-07 19:03:46]

The patchset sent to the CQ was uploaded after l-g-t-m from
vollick@chromium.org, ajuma@chromium.org
Link to the patchset: https://codereview.chromium.org/1864183002/#ps80001
(title: "Format the comments")

[commit-bot: I haz the power, 2016-04-07 19:04:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1864183002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1864183002/80001

[commit-bot: I haz the power, 2016-04-07 20:29:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-07 20:29:10]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[sunxd, 2016-04-08 15:20:53]

The CQ bit was checked by sunxd@chromium.org

[commit-bot: I haz the power, 2016-04-08 15:21:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1864183002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1864183002/80001

[commit-bot: I haz the power, 2016-04-08 15:26:58]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main 
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use the iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main 
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use the iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-04-08 15:27:00]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-04-08 15:27:54]

Description was changed from

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main 
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use the iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Main thread skip single layers instead of subtrees

This is a mirror change of issue 1811423002 on the main
thread. After getting rid of tree hierarchy in LayerTreeHost,
we won't be able to skip subtrees, instead we skip every
single layer.

The behavior remains unchanged: a layer is skipped when it
meets the legacy subtree-skipping criteria or one of its
ancestors meets.

The follow-up patch will remove CallFunctionForEveryLayer and
use the iterator instead.

BUG=600509
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/0f10629e6702683168b2ce68fa2e50d2a5594f25
Cr-Commit-Position: refs/heads/master@{#386083}
==========

[commit-bot: I haz the power, 2016-04-08 15:27:55]

Patchset 5 (id:??) landed as
https://crrev.com/0f10629e6702683168b2ce68fa2e50d2a5594f25
Cr-Commit-Position: refs/heads/master@{#386083}