Setup LayerTree class, refactor 2 functions from LayerTreeHost to it.

Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/e43518a18ef7736ece1beadde0c7e57e5ed7dd88
Cr-Commit-Position: refs/heads/master@{#408518}

[xingliu, 2016-07-16 02:13:33]

Description was changed from

==========
Setup LayerTree class, refactor 2 functions from LayerTreeHost to it.

In the future LayerTreeHost will be an interface and internal cc class will talk
to LayerTree instead. We will graduately refactor LayerTreeHost.

BUG=628683
==========

to

==========
Setup LayerTree class, refactor 2 functions from LayerTreeHost to it.

In the future LayerTreeHost will be an interface and internal cc class will talk
to LayerTree instead. We will graduately refactor LayerTreeHost.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

[xingliu, 2016-07-16 02:36:30]

xingliu@chromium.org changed reviewers:
+ khushalsagar@chromium.org

[xingliu, 2016-07-16 02:36:31]

Refactor two functions into LayerTree.

[xingliu, 2016-07-16 02:36:38]

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

[commit-bot: I haz the power, 2016-07-16 02:36:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-16 03:25:16]

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

[commit-bot: I haz the power, 2016-07-16 03:25:17]

Dry run: This issue passed the CQ dry run.

[Khushal, 2016-07-18 16:59:33]

Looks good xing!

https://codereview.chromium.org/2159513003/diff/1/cc/BUILD.gn
File cc/BUILD.gn (right):

https://codereview.chromium.org/2159513003/diff/1/cc/BUILD.gn#newcode498
cc/BUILD.gn:498: "trees/layer_tree.cc",
This will need a gyp change too.

https://codereview.chromium.org/2159513003/diff/1/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2159513003/diff/1/cc/layers/layer.cc#newcode218
cc/layers/layer.cc:218:
layer_tree_host_->layer_tree()->AddLayerShouldPushProperties(this);
I would suggest add a public method to Layer to access the LayerTree.

LayerTree* GetLayerTree() const {
  return layer_tree_host_ ? layer_tree_host_->layer_tree() : nullptr;
}

And then you can start moving the call sites to use the layer tree as you move
functionalities there. This way when you finally change Layer::SetLayerTreeHost
to Layer::SetLayerTree, you won't have to change all the call sites.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h
File cc/trees/layer_tree.h (right):

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h#newco...
cc/trees/layer_tree.h:25: class CC_EXPORT LayerTree {
I would suggest move Register/UnregisterLayer to the LayerTree as well. And the
methods that return the LayerListIterator. And have the dependent call sites use
the LayerTree instead.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h#newco...
cc/trees/layer_tree.h:34: void FromProtobuf(const proto::LayerTree& proto,
LayerIdMap* layer_id_map);
The LayerIdMap would move to the LayerTree, wouldn't need to pass it in here
then.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h#newco...
cc/trees/layer_tree.h:35: LayerSet& layers_that_should_push_properties();
You shouldn't have to expose this after you move the methods above.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:256: layer_tree_() {
Don't need to initialize it for a default ctor.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:1349: void
LayerTreeHost::AddLayerShouldPushProperties(Layer* layer) {
Why do we still need these methods on the host? This is being done in the
LayerTree now.

You should move all of the methods below for maintaining the LayerIdMap and
tracking which layers should push properties to the LayerTree and move all
accesses directly to it.

layer_tree_host->GetLayerTree()->RegisterLayer(layer).

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:430: LayerTree* layer_tree() { return &layer_tree_; }
Can you change this to LayerTree* GetLayerTree() const; and define in the
header? When the method is added to the LayerTreeHost interface it won't be an
accessor.

[xingliu, 2016-07-19 22:03:19]

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

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

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[xingliu, 2016-07-19 22:47:38]

Refactored more functions.

https://codereview.chromium.org/2159513003/diff/1/cc/BUILD.gn
File cc/BUILD.gn (right):

https://codereview.chromium.org/2159513003/diff/1/cc/BUILD.gn#newcode498
cc/BUILD.gn:498: "trees/layer_tree.cc",
On 2016/07/18 16:59:32, Khushal wrote:
> This will need a gyp change too.

Done.

https://codereview.chromium.org/2159513003/diff/1/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2159513003/diff/1/cc/layers/layer.cc#newcode218
cc/layers/layer.cc:218:
layer_tree_host_->layer_tree()->AddLayerShouldPushProperties(this);
On 2016/07/18 16:59:32, Khushal wrote:
> I would suggest add a public method to Layer to access the LayerTree.
> 
> LayerTree* GetLayerTree() const {
>   return layer_tree_host_ ? layer_tree_host_->layer_tree() : nullptr;
> }
> 
> And then you can start moving the call sites to use the layer tree as you move
> functionalities there. This way when you finally change
Layer::SetLayerTreeHost
> to Layer::SetLayerTree, you won't have to change all the call sites.

Done. Good idea.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h
File cc/trees/layer_tree.h (right):

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h#newco...
cc/trees/layer_tree.h:25: class CC_EXPORT LayerTree {
On 2016/07/18 16:59:33, Khushal wrote:
> I would suggest move Register/UnregisterLayer to the LayerTree as well. And
the
> methods that return the LayerListIterator. And have the dependent call sites
use
> the LayerTree instead.

Register/UnregisterLayer moved to LayerTree.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h#newco...
cc/trees/layer_tree.h:34: void FromProtobuf(const proto::LayerTree& proto,
LayerIdMap* layer_id_map);
On 2016/07/18 16:59:32, Khushal wrote:
> The LayerIdMap would move to the LayerTree, wouldn't need to pass it in here
> then.

Done.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree.h#newco...
cc/trees/layer_tree.h:35: LayerSet& layers_that_should_push_properties();
On 2016/07/18 16:59:33, Khushal wrote:
> You shouldn't have to expose this after you move the methods above.

Done.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.cc
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:256: layer_tree_() {
On 2016/07/18 16:59:33, Khushal wrote:
> Don't need to initialize it for a default ctor.

Done.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.cc...
cc/trees/layer_tree_host.cc:1349: void
LayerTreeHost::AddLayerShouldPushProperties(Layer* layer) {
On 2016/07/18 16:59:33, Khushal wrote:
> Why do we still need these methods on the host? This is being done in the
> LayerTree now.
> 
> You should move all of the methods below for maintaining the LayerIdMap and
> tracking which layers should push properties to the LayerTree and move all
> accesses directly to it.
> 
> layer_tree_host->GetLayerTree()->RegisterLayer(layer).

Done.

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.h
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2159513003/diff/1/cc/trees/layer_tree_host.h#...
cc/trees/layer_tree_host.h:430: LayerTree* layer_tree() { return &layer_tree_; }
On 2016/07/18 16:59:33, Khushal wrote:
> Can you change this to LayerTree* GetLayerTree() const; and define in the
> header? When the method is added to the LayerTreeHost interface it won't be an
> accessor.

Done.

[xingliu, 2016-07-19 22:48:20]

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

[commit-bot: I haz the power, 2016-07-19 22:48:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-20 00:17:11]

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

[commit-bot: I haz the power, 2016-07-20 00:17:12]

Dry run: This issue passed the CQ dry run.

[Khushal, 2016-07-20 00:46:51]

khushalsagar@chromium.org changed reviewers:
+ ajuma@chromium.org, vmpstr@chromium.org

[Khushal, 2016-07-20 00:46:52]

+vmpstr for a general review.

+ajuma for AnimationHost ownership. There was a discussion in the doc about
whether it should be with the LayerTree or the LayerTreeHost. Could you suggest
what would be better?
(https://docs.google.com/document/d/1dUlpEa4NEictRcdLYkxjoJ-1xdh7MF-fHxR05vmH2IY)

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:253: layer_tree_(&(params->animation_host)) {
You don't need to pass a reference to the unique_ptr, you can std::move the ptr
itself.

LayerTree(std::unique_ptr<AnimationHost> animation_host) would be the ctor.

And in the initialization here, layer_tree_(std::move(params->animation_host)).

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:1051: bool& in_paint_layer_contents =
GetLayerTree()->get_in_paint_layer_contents();
I think we can have the iteration through the layers during update happen in the
LayerTree itself, so you can set the flag there.

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:1348: bool
LayerTreeHost::LayerNeedsPushPropertiesForTesting(Layer* layer) {
Since we are moving all tracking for layers that are dirty to the LayerTree, you
can move this method there as well.

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/tree_synchroni...
File cc/trees/tree_synchronizer.h (right):

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/tree_synchroni...
cc/trees/tree_synchronizer.h:34: static void PushLayerProperties(LayerTreeHost*
host_tree,
Is there a reason why we still need the the PushPropertiesTo method with the
LayerTreeHost?

[Khushal, 2016-07-20 00:55:58]

Also could you update the Cl description. Something along the lines of,

Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

[xingliu, 2016-07-20 01:13:54]

Description was changed from

==========
Setup LayerTree class, refactor 2 functions from LayerTreeHost to it.

In the future LayerTreeHost will be an interface and internal cc class will talk
to LayerTree instead. We will graduately refactor LayerTreeHost.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

to

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

[ajuma, 2016-07-20 15:35:01]

On 2016/07/20 00:46:52, Khushal wrote:
> +vmpstr for a general review.
> 
> +ajuma for AnimationHost ownership. There was a discussion in the doc about
> whether it should be with the LayerTree or the LayerTreeHost. Could you
suggest
> what would be better?
>
(https://docs.google.com/document/d/1dUlpEa4NEictRcdLYkxjoJ-1xdh7MF-fHxR05vmH2IY)

I think it should be owned by the LayerTreeHost since it feels more like
something that acts on the tree rather than being a property of the tree. But I
think it makes sense for the LayerTree to be the MutatorHostClient since it's
the thing that gets mutated. Are there advantages to making the AnimationHost
owned by the LayerTree instead?

[Khushal, 2016-07-20 18:56:02]

On 2016/07/20 15:35:01, ajuma wrote:
> On 2016/07/20 00:46:52, Khushal wrote:
> > +vmpstr for a general review.
> > 
> > +ajuma for AnimationHost ownership. There was a discussion in the doc about
> > whether it should be with the LayerTree or the LayerTreeHost. Could you
> suggest
> > what would be better?
> >
>
(https://docs.google.com/document/d/1dUlpEa4NEictRcdLYkxjoJ-1xdh7MF-fHxR05vmH2IY)
> 
> I think it should be owned by the LayerTreeHost since it feels more like
> something that acts on the tree rather than being a property of the tree. But
I
> think it makes sense for the LayerTree to be the MutatorHostClient since it's
> the thing that gets mutated. Are there advantages to making the AnimationHost
> owned by the LayerTree instead?

I was also more inclined to have the MutatorHostClient be implemented by the
LayerTree, so all the code which is about mutating the tree state lives in
LayerTree, and doesn't have to be duplicated. For the ownership, I presumed that
we have the host own it on the impl thread because the AnimationHost has state
for both the pending and active tree. Since the LayerTree lifetime on main
thread is tied to the lifetime of the LayerTreeHost, I couldn't think of a
strong reason to keep it on the host. I don't have a strong opinion on it,
whatever you think is best. :)

[ajuma, 2016-07-20 20:30:22]

On 2016/07/20 18:56:02, Khushal wrote:
> On 2016/07/20 15:35:01, ajuma wrote:
> > On 2016/07/20 00:46:52, Khushal wrote:
> > > +vmpstr for a general review.
> > > 
> > > +ajuma for AnimationHost ownership. There was a discussion in the doc
about
> > > whether it should be with the LayerTree or the LayerTreeHost. Could you
> > suggest
> > > what would be better?
> > >
> >
>
(https://docs.google.com/document/d/1dUlpEa4NEictRcdLYkxjoJ-1xdh7MF-fHxR05vmH2IY)
> > 
> > I think it should be owned by the LayerTreeHost since it feels more like
> > something that acts on the tree rather than being a property of the tree.
But
> I
> > think it makes sense for the LayerTree to be the MutatorHostClient since
it's
> > the thing that gets mutated. Are there advantages to making the
AnimationHost
> > owned by the LayerTree instead?
> 
> I was also more inclined to have the MutatorHostClient be implemented by the
> LayerTree, so all the code which is about mutating the tree state lives in
> LayerTree, and doesn't have to be duplicated. For the ownership, I presumed
that
> we have the host own it on the impl thread because the AnimationHost has state
> for both the pending and active tree. Since the LayerTree lifetime on main
> thread is tied to the lifetime of the LayerTreeHost, I couldn't think of a
> strong reason to keep it on the host. I don't have a strong opinion on it,
> whatever you think is best. :)

Having it owned by the LayerTree (and making LayerTree implement
MutatorHostClient) sounds fine (I think I was interpreting the LayerTree name a
bit too literally when I suggested that it be owned by LayerTreeHost).

[xingliu, 2016-07-20 20:32:06]

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

[commit-bot: I haz the power, 2016-07-20 20:32:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[xingliu, 2016-07-20 20:33:07]

Fixed a couple of issues based on code review.

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:253: layer_tree_(&(params->animation_host)) {
On 2016/07/20 00:46:51, Khushal wrote:
> You don't need to pass a reference to the unique_ptr, you can std::move the
ptr
> itself.
> 
> LayerTree(std::unique_ptr<AnimationHost> animation_host) would be the ctor.
> 
> And in the initialization here,
layer_tree_(std::move(params->animation_host)).
Done, maybe release() and pass raw pointer to LayerTree is more clear?

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:1051: bool& in_paint_layer_contents =
GetLayerTree()->get_in_paint_layer_contents();
On 2016/07/20 00:46:51, Khushal wrote:
> I think we can have the iteration through the layers during update happen in
the
> LayerTree itself, so you can set the flag there.

Done.

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:1348: bool
LayerTreeHost::LayerNeedsPushPropertiesForTesting(Layer* layer) {
On 2016/07/20 00:46:51, Khushal wrote:
> Since we are moving all tracking for layers that are dirty to the LayerTree,
you
> can move this method there as well.

Done.

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/tree_synchroni...
File cc/trees/tree_synchronizer.h (right):

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/tree_synchroni...
cc/trees/tree_synchronizer.h:34: static void PushLayerProperties(LayerTreeHost*
host_tree,
On 2016/07/20 00:46:52, Khushal wrote:
> Is there a reason why we still need the the PushPropertiesTo method with the
> LayerTreeHost?

Fixed.

[commit-bot: I haz the power, 2016-07-20 20:35:49]

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

[commit-bot: I haz the power, 2016-07-20 20:35:50]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-gn/bui...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[xingliu, 2016-07-20 20:41:48]

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

[commit-bot: I haz the power, 2016-07-20 20:42:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-20 20:44:26]

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

[commit-bot: I haz the power, 2016-07-20 20:44:27]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-gn/bui...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)

[Khushal, 2016-07-20 21:29:48]

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/40001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host.cc:253: layer_tree_(&(params->animation_host)) {
On 2016/07/20 20:33:06, xingliu wrote:
> On 2016/07/20 00:46:51, Khushal wrote:
> > You don't need to pass a reference to the unique_ptr, you can std::move the
> ptr
> > itself.
> > 
> > LayerTree(std::unique_ptr<AnimationHost> animation_host) would be the ctor.
> > 
> > And in the initialization here,
> layer_tree_(std::move(params->animation_host)).
> Done, maybe release() and pass raw pointer to LayerTree is more clear?

Use unique pointers if you're passing ownership, it makes it very clear. If you
get a raw pointer, its unclear whether you're just getting a weak reference or
you're supposed to take ownership.

https://codereview.chromium.org/2159513003/diff/60001/cc/trees/layer_tree.h
File cc/trees/layer_tree.h (right):

https://codereview.chromium.org/2159513003/diff/60001/cc/trees/layer_tree.h#n...
cc/trees/layer_tree.h:49: void set_in_paint_layer_contents(bool value);
Do we still need a setter for this? It should be set only when the LayerTree is
updating the layers.

[xingliu, 2016-07-20 22:40:33]

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

[commit-bot: I haz the power, 2016-07-20 22:41:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-20 23:13:30]

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

[commit-bot: I haz the power, 2016-07-20 23:13:31]

Dry run: Try jobs failed on following builders:
  win8_chromium_gyp_rel on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gyp...)

[Khushal, 2016-07-20 23:14:10]

lgtm. Thanks!

https://codereview.chromium.org/2159513003/diff/100001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/100001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host.cc:1494: // Serialize LayerTree before
LayerTree.layers_that_should_push_properties_
You probably meant "Serialize the LayerTree before serializing the properties.
During layer property serialization, we clear the list
|layer_that_should_properties_| from the LayerTree."

[xingliu, 2016-07-20 23:47:22]

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

[commit-bot: I haz the power, 2016-07-20 23:47:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-21 00:50:02]

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

[commit-bot: I haz the power, 2016-07-21 00:50:03]

Dry run: This issue passed the CQ dry run.

[xingliu, 2016-07-22 17:15:28]

On 2016/07/20 23:14:10, Khushal wrote:
> lgtm. Thanks!
> 
>
https://codereview.chromium.org/2159513003/diff/100001/cc/trees/layer_tree_ho...
> File cc/trees/layer_tree_host.cc (right):
> 
>
https://codereview.chromium.org/2159513003/diff/100001/cc/trees/layer_tree_ho...
> cc/trees/layer_tree_host.cc:1494: // Serialize LayerTree before
> LayerTree.layers_that_should_push_properties_
> You probably meant "Serialize the LayerTree before serializing the properties.
> During layer property serialization, we clear the list
> |layer_that_should_properties_| from the LayerTree."

Thank you.

[xingliu, 2016-07-25 15:50:43]

On 2016/07/22 17:15:28, xingliu wrote:
> On 2016/07/20 23:14:10, Khushal wrote:
> > lgtm. Thanks!
> > 
> >
>
https://codereview.chromium.org/2159513003/diff/100001/cc/trees/layer_tree_ho...
> > File cc/trees/layer_tree_host.cc (right):
> > 
> >
>
https://codereview.chromium.org/2159513003/diff/100001/cc/trees/layer_tree_ho...
> > cc/trees/layer_tree_host.cc:1494: // Serialize LayerTree before
> > LayerTree.layers_that_should_push_properties_
> > You probably meant "Serialize the LayerTree before serializing the
properties.
> > During layer property serialization, we clear the list
> > |layer_that_should_properties_| from the LayerTree."
> 
> Thank you.

pinned, thanks for the review.

[vmpstr, 2016-07-25 20:45:46]

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc#new...
cc/layers/layer.cc:1854: return layer_tree_host_ ?
layer_tree_host_->GetLayerTree() : nullptr;
If we're mimicking impl side of things, then layer_tree_impl is passed into the
ctor of layer_impl. Can we do a similar thing for the main side?

LayerTreeHost owns LayerTree which owns Layers, so it's a bit awkward for

Layer to talk to LayerTreeHost in order to get its LayerTree.

Most, if not all, interactions on the impl side happen from LayerImpl to
LayerTreeImpl, which may or may not forward the call to LayerTreeHostImpl. Is
this the plan in the future?

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host.cc:367:
GetLayerTree()->animation_host()->SetSupportsScrollAnimations(
I think it's a bit silly to access LayerTree from LTH via GetLayerTree. It is
after all a non-pointer member of LTH, and GetLayerTree returns its address,
only so that you can dereference it again to get the member.

Can we replace GetLayerTree()-> with layer_tree_. in this file?

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host.h:596: LayerTree layer_tree_;
Which of the LTH members will go into LayerTree?

[xingliu, 2016-07-25 23:40:25]

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc#new...
cc/layers/layer.cc:1854: return layer_tree_host_ ?
layer_tree_host_->GetLayerTree() : nullptr;
On 2016/07/25 20:45:46, vmpstr wrote:
> If we're mimicking impl side of things, then layer_tree_impl is passed into
the
> ctor of layer_impl. Can we do a similar thing for the main side?
> 
> LayerTreeHost owns LayerTree which owns Layers, so it's a bit awkward for
> 
> Layer to talk to LayerTreeHost in order to get its LayerTree.
> 
> Most, if not all, interactions on the impl side happen from LayerImpl to
> LayerTreeImpl, which may or may not forward the call to LayerTreeHostImpl. Is
> this the plan in the future?

@Khushal

Khushal probably can answer this question much better than me.

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host.cc (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host.cc:367:
GetLayerTree()->animation_host()->SetSupportsScrollAnimations(
On 2016/07/25 20:45:46, vmpstr wrote:
> I think it's a bit silly to access LayerTree from LTH via GetLayerTree. It is
> after all a non-pointer member of LTH, and GetLayerTree returns its address,
> only so that you can dereference it again to get the member.
> 
> Can we replace GetLayerTree()-> with layer_tree_. in this file?

Yes.

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host.h:596: LayerTree layer_tree_;
On 2016/07/25 20:45:46, vmpstr wrote:
> Which of the LTH members will go into LayerTree?

Animation host, data structure to hold layers, MutatorHostClient interface and
members mainly used by those things will go to LayerTree.

@Khushal, please correct me if I'm wrong.

[Khushal, 2016-07-26 18:10:42]

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc#new...
cc/layers/layer.cc:1854: return layer_tree_host_ ?
layer_tree_host_->GetLayerTree() : nullptr;
On 2016/07/25 20:45:46, vmpstr wrote:
> If we're mimicking impl side of things, then layer_tree_impl is passed into
the
> ctor of layer_impl. Can we do a similar thing for the main side?

Not sure. Blink uses the WebCompositorSupportImpl to build the WebLayers
wrapping the cc::Layers and that's shared across the RWCs which have the LTH. In
Clank UI as well, they just create Layers and don't have access to the LTH,
since its owned by the CompositorImpl in content/, so you just set the root
layer on the compositor which gives it to the host and it attaches itself to the
underlying tree. I figured the reason we have the SetLayerTreeHost method on
Layers is because you can construct one and then attach or detach it from the
LTH or change hosts? LayerImpls on the other hand remain bound to the
LayerTreeImpl right?

> 
> LayerTreeHost owns LayerTree which owns Layers, so it's a bit awkward for
> 
> Layer to talk to LayerTreeHost in order to get its LayerTree.
> 
> Most, if not all, interactions on the impl side happen from LayerImpl to
> LayerTreeImpl, which may or may not forward the call to LayerTreeHostImpl. Is
> this the plan in the future?

Yup, LayerTreeHost wouldn't exist, so SetLayerTreeHost would change to
SetLayerTree.

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host.h:596: LayerTree layer_tree_;
On 2016/07/25 23:40:25, xingliu wrote:
> On 2016/07/25 20:45:46, vmpstr wrote:
> > Which of the LTH members will go into LayerTree?
> 
> Animation host, data structure to hold layers, MutatorHostClient interface and
> members mainly used by those things will go to LayerTree.
> 
> @Khushal, please correct me if I'm wrong.

Yup, basically all data that is mutated/computed on the main thread side to be
pushed to impl during a commit, including PropertyTrees.

[vmpstr, 2016-07-27 18:05:29]

vmpstr@chromium.org changed reviewers:
+ danakj@chromium.org

[vmpstr, 2016-07-27 18:05:30]

In some places where you have

root->layer_tree_host()->GetLayerTree(), can that be changed to
root->GetLayerTree()? 

Also, my general comment is that I find it a bit awkward that we can have layers
without a layer tree. LayerTree as the name suggests to me that it's a bundle of
layers representing the full tree. So, how would one get a Layer without a
LayerTree? I understand why it's the case here, but I kind of wish this was
structured differently. 

I think this change makes sense though if you make the changes in the comments. 

+danakj as well to see if there are any objections.

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc
File cc/layers/layer.cc (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.cc#new...
cc/layers/layer.cc:217: if (layer_tree_host_)
if (GetLayerTree()) here and throughout

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.h
File cc/layers/layer.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.h#newc...
cc/layers/layer.h:397: LayerTree* GetLayerTree() const;
nit: Can you add a TODO to create an interface and this function will be a part
of it? I've talked to Khushal and I think that's the intent.

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree.h
File cc/trees/layer_tree.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree.h#...
cc/trees/layer_tree.h:24: using LayerSet = std::unordered_set<Layer*>;
Can this be internal to LayerTree or is it used elsewhere?

[xingliu, 2016-07-28 04:04:18]

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

[commit-bot: I haz the power, 2016-07-28 04:04:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 04:04:37]

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

[commit-bot: I haz the power, 2016-07-28 04:04:38]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 16:07:24]

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

[commit-bot: I haz the power, 2016-07-28 16:07:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 16:07:43]

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

[commit-bot: I haz the power, 2016-07-28 16:07:45]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 16:08:27]

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

[commit-bot: I haz the power, 2016-07-28 16:08:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 16:08:45]

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

[commit-bot: I haz the power, 2016-07-28 16:08:46]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 16:10:24]

Fix couple of issues according to codereview.

Mainly includes: 

1. Now layer hold pointer of both layer_tree and layer_tree_host,

2. In layer_tree_host, directly use layer_tree_ pointer.

3. Removed redundant calls in test code.

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.h
File cc/layers/layer.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/layers/layer.h#newc...
cc/layers/layer.h:397: LayerTree* GetLayerTree() const;
On 2016/07/27 18:05:30, vmpstr wrote:
> nit: Can you add a TODO to create an interface and this function will be a
part
> of it? I've talked to Khushal and I think that's the intent. 

Done.

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree.h
File cc/trees/layer_tree.h (right):

https://codereview.chromium.org/2159513003/diff/120001/cc/trees/layer_tree.h#...
cc/trees/layer_tree.h:24: using LayerSet = std::unordered_set<Layer*>;
On 2016/07/27 18:05:30, vmpstr wrote:
> Can this be internal to LayerTree or is it used elsewhere?

Done.

[xingliu, 2016-07-28 16:10:47]

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

[commit-bot: I haz the power, 2016-07-28 16:11:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 16:11:04]

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

[commit-bot: I haz the power, 2016-07-28 16:11:05]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 16:13:55]

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

[commit-bot: I haz the power, 2016-07-28 16:14:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 16:14:19]

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

[commit-bot: I haz the power, 2016-07-28 16:14:20]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 16:53:12]

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

[commit-bot: I haz the power, 2016-07-28 16:53:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 16:53:29]

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

[commit-bot: I haz the power, 2016-07-28 16:53:30]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 17:52:21]

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

[commit-bot: I haz the power, 2016-07-28 17:52:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 17:52:44]

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

[commit-bot: I haz the power, 2016-07-28 17:52:45]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[xingliu, 2016-07-28 17:59:46]

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

[commit-bot: I haz the power, 2016-07-28 17:59:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 17:59:59]

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

[commit-bot: I haz the power, 2016-07-28 18:00:00]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[Khushal, 2016-07-28 18:03:11]

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

[commit-bot: I haz the power, 2016-07-28 18:03:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 18:03:30]

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

[commit-bot: I haz the power, 2016-07-28 18:03:31]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * master.tryserver.blink builder linux_blink_rel was renamed to
linux_precise_blink_rel (http://crbug.com/590036)

[Khushal, 2016-07-28 18:14:57]

Description was changed from

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_blink_rel
==========

to

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Khushal, 2016-07-28 18:15:11]

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

[commit-bot: I haz the power, 2016-07-28 18:15:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 20:24:07]

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

[commit-bot: I haz the power, 2016-07-28 20:24:09]

Dry run: This issue passed the CQ dry run.

[vmpstr, 2016-07-28 21:43:22]

lgtm

https://codereview.chromium.org/2159513003/diff/180001/cc/proto/layer_tree.proto
File cc/proto/layer_tree.proto (right):

https://codereview.chromium.org/2159513003/diff/180001/cc/proto/layer_tree.pr...
cc/proto/layer_tree.proto:12: repeated int32 layers_that_should_push_properties
= 1;
Maybe we should name these with "id" in the name, kind of like
layer_ids_that_should_push_properties?

https://codereview.chromium.org/2159513003/diff/180001/cc/proto/layer_tree.pr...
cc/proto/layer_tree.proto:13: optional bool in_paint_layer_contents = 2;
This looks like it's a transitive state that shouldn't be serialized. That is,
it is temporarily true, but mostly false.

[Khushal, 2016-07-28 21:52:20]

https://codereview.chromium.org/2159513003/diff/180001/cc/proto/layer_tree.proto
File cc/proto/layer_tree.proto (right):

https://codereview.chromium.org/2159513003/diff/180001/cc/proto/layer_tree.pr...
cc/proto/layer_tree.proto:13: optional bool in_paint_layer_contents = 2;
On 2016/07/28 21:43:22, vmpstr wrote:
> This looks like it's a transitive state that shouldn't be serialized. That is,
> it is temporarily true, but mostly false. 

Yup, the aim is to move stuff that actually needs to be serialized into seperate
structs, so both computed and helper variables are not serialized.

[xingliu, 2016-07-28 23:02:30]

The CQ bit was checked by xingliu@chromium.org

[xingliu, 2016-07-28 23:02:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
khushalsagar@chromium.org
Link to the patchset: https://codereview.chromium.org/2159513003/#ps180001
(title: "Layer GetLayerTree now directly uses LayerTree pointer.")

[commit-bot: I haz the power, 2016-07-28 23:03:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 00:00:01]

Description was changed from

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

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

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-07-29 00:02:11]

Description was changed from

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Set up a LayerTree class to split the LayerTreeHost.

The LayerTree class is the main thread counter-part to the LayerTreeImpl, which
will own the root layer and other tree state. Data and functionality will be
incrementally moved to this class as we eliminate dependencies of internal cc
class and the embedder to LayerTree from the host.

This patch moves the Registration/Unregistration logic for maintaining a map of
layers tied to a host and tracking of dirty layers that need to push properties
in the next commit, to the LayerTree.

BUG=628683
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/e43518a18ef7736ece1beadde0c7e57e5ed7dd88
Cr-Commit-Position: refs/heads/master@{#408518}
==========

[commit-bot: I haz the power, 2016-07-29 00:02:13]

Patchset 10 (id:??) landed as
https://crrev.com/e43518a18ef7736ece1beadde0c7e57e5ed7dd88
Cr-Commit-Position: refs/heads/master@{#408518}

[xingliu, 2016-07-30 03:00:48]

Thanks all for the review!