cc: Split out calcDrawEtc from drawLayers

cc/tree_synchronizer.cc

 // Copyright 2011 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 "cc/tree_synchronizer.h"
 
 #include "base/debug/trace_event.h"
 #include "cc/layer.h"
 #include "cc/layer_impl.h"
 #include "cc/scrollbar_animation_controller.h"
@@ skipping 44 matching lines @@
     return layerImpl.Pass();
 }
 
 scoped_ptr<LayerImpl> TreeSynchronizer::synchronizeTreeRecursive(RawPtrLayerImplMap& newLayers, ScopedPtrLayerImplMap& oldLayers, Layer* layer, LayerTreeHostImpl* hostImpl)
 {
     if (!layer)
         return scoped_ptr<LayerImpl>();
 
     scoped_ptr<LayerImpl> layerImpl = reuseOrCreateLayerImpl(newLayers, oldLayers, layer);
 
+    // This call is not strictly necessary, but it prevents an extra tree
+    // recursion to set the host after synchronization in setRootLayer.
+    layerImpl->setLayerTreeHostImpl(hostImpl);

[danakj, 2012/12/06 19:12:10]

Now the cc::Layer will be able to reach through and poke the LTHImpl in
pushPropertiesTo() which I'm not sure I'm crazy about. What do you think about
that?

Maybe we could move the pushPropertiesTo() call up above this?

[enne (OOO), 2012/12/06 19:25:42]

Is there something wrong with that?

[danakj, 2012/12/06 19:32:20]

I'm not sure :) I know it's informed design choices in the past, and possibly
made for better (or worse) choices in the end. It enforces a bit of separation
in that the main thread layer can't really start poking easily at the whole impl
tree.

[enne (OOO), 2012/12/06 19:34:09]

It has?? I don't have any sense of what you're referring to here. Do you have a
specific example you're thinking of?

[danakj, 2012/12/06 19:36:20]

I'm trying to remember what it was, but at least once I was going to do
something in there, I think it was for HudLayer, and this made me look for
another way.

[enne (OOO), 2012/12/06 19:49:02]

"I had to do something another way because I didn't want to change this" isn't a
really strong argument.  ;)

What could go wrong here? What would not doing this prevent?

[danakj, 2012/12/06 19:51:56]

I'm not really sure, I just wanted to make sure you'd thought about it before
doing it and it wasn't an accident.

I'm okay with it otherwise as I have no arguments really.

+
     layerImpl->clearChildList();
     const std::vector<scoped_refptr<Layer> >& children = layer->children();
     for (size_t i = 0; i < children.size(); ++i)
         layerImpl->addChild(synchronizeTreeRecursive(newLayers, oldLayers, children[i].get(), hostImpl));
 
     layerImpl->setMaskLayer(synchronizeTreeRecursive(newLayers, oldLayers, layer->maskLayer(), hostImpl));
     layerImpl->setReplicaLayer(synchronizeTreeRecursive(newLayers, oldLayers, layer->replicaLayer(), hostImpl));
 
     layer->pushPropertiesTo(layerImpl.get());
-    layerImpl->setLayerTreeHostImpl(hostImpl);
 
     // Remove all dangling pointers. The pointers will be setup later in updateScrollbarLayerPointersRecursive phase
     if (ScrollbarAnimationController* scrollbarController = layerImpl->scrollbarAnimationController()) {
         scrollbarController->setHorizontalScrollbarLayer(0);
         scrollbarController->setVerticalScrollbarLayer(0);
     }
 
     return layerImpl.Pass();
 }
 
@@ skipping 18 matching lines @@
     DCHECK(scrollbarLayerImpl);
     DCHECK(scrollLayerImpl);
 
     if (scrollbarLayerImpl->orientation() == WebKit::WebScrollbar::Horizontal)
         scrollLayerImpl->setHorizontalScrollbarLayer(scrollbarLayerImpl);
     else
         scrollLayerImpl->setVerticalScrollbarLayer(scrollbarLayerImpl);
 }
 
 }  // namespace cc