cc: Start using raster/eviction iterators.

cc/trees/layer_tree_host_impl.cc

Index: cc/trees/layer_tree_host_impl.cc
diff --git a/cc/trees/layer_tree_host_impl.cc b/cc/trees/layer_tree_host_impl.cc
index de1e8ffcacd26e2befe65d392552ba699e0a7b75..7189773c2b81d85f442657b46498f3fd32001803 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -1223,7 +1223,8 @@ void LayerTreeHostImpl::DidInitializeVisibleTile() {
     client_->DidInitializeVisibleTileOnImplThread();
 }
 
-const std::vector<PictureLayerImpl*>& LayerTreeHostImpl::GetPictureLayers() {
+const std::vector<PictureLayerImpl*>& LayerTreeHostImpl::GetPictureLayers()
+    const {
   return picture_layers_;
 }
 
@@ -1249,6 +1250,25 @@ void LayerTreeHostImpl::NotifyTileStateChanged(const Tile* tile) {
   }
 }
 
+RasterTileQueue* LayerTreeHostImpl::GetRasterQueue(TreePriority tree_priority) {
+  // TODO(vmpstr): Investigate if we can skip preparation if nothing changed
+  // (priorities, etc)
+  std::vector<PairedPictureLayer> paired_layers;
+  GetPairedPictureLayers(&paired_layers);
+  raster_queue_.Prepare(paired_layers, tree_priority);

[reveman, 2014/07/09 02:21:09]

I don't think we should use a client function to trigger work that needs to be
done before the queue can be used. I'd rather see us handle that transparently
to the tile manager by preparing the queue or marking it as needing to be
prepared before use as needed.

I don't care how much you optimize this in this patch. You can call Prepare()
before each ManageTiles and whenever a layer is added/removed as far as I care.
I'm just interested in making the interface to the tile manager such that we can
optimize this as much as we like in the future without having to change how we
interact with the tile manager.

[vmpstr, 2014/07/09 18:35:38]

Calling prepare in tile manager seems like a wrong thing to do. I'd like to see
tile manager simply use these queues, without any knowledge of what needs to be
done to them before they are ready to be consumed. Also, preparing requires a
set of layer pairs, and I'd like to avoid both having tile manager get those
pairs and having a client back pointer in the queues.

All in all, when we call prepare can be changed, but I still think tile manager
should not know how to initialize the queues. Would you agree to this solution
as a way that makes tile manager interface simple? I'm willing to work on
figuring out the ideal spot for prepare as a follow-up.

+  return &raster_queue_;
+}
+
+EvictionTileQueue* LayerTreeHostImpl::GetEvictionQueue(
+    TreePriority tree_priority) {
+  // TODO(vmpstr): Investigate if we can skip preparation if nothing changed
+  // (priorities, etc)
+  std::vector<PairedPictureLayer> paired_layers;
+  GetPairedPictureLayers(&paired_layers);
+  eviction_queue_.Prepare(paired_layers, tree_priority);
+  return &eviction_queue_;
+}
+
 void LayerTreeHostImpl::SetMemoryPolicy(const ManagedMemoryPolicy& policy) {
   SetManagedMemoryPolicy(policy, zero_budget_);
 }
@@ -1974,6 +1994,49 @@ void LayerTreeHostImpl::EnforceZeroBudget(bool zero_budget) {
   SetManagedMemoryPolicy(cached_managed_memory_policy_, zero_budget);
 }
 
+void LayerTreeHostImpl::GetPairedPictureLayers(
+    std::vector<PairedPictureLayer>* paired_layers) const {
+  const std::vector<PictureLayerImpl*>& layers = GetPictureLayers();
+
+  paired_layers->clear();
+  // Reserve a maximum possible paired layers.
+  paired_layers->reserve(layers.size());
+
+  for (std::vector<PictureLayerImpl*>::const_iterator it = layers.begin();
+       it != layers.end();
+       ++it) {
+    PictureLayerImpl* layer = *it;
+
+    // TODO(vmpstr): Iterators and should handle this instead. crbug.com/381704
+    if (!layer->HasValidTilePriorities())
+      continue;
+
+    PictureLayerImpl* twin_layer = layer->GetTwinLayer();
+
+    // Ignore the twin layer when tile priorities are invalid.
+    // TODO(vmpstr): Iterators should handle this instead. crbug.com/381704
+    if (twin_layer && !twin_layer->HasValidTilePriorities())
+      twin_layer = NULL;
+
+    PairedPictureLayer paired_layer;
+    WhichTree tree = layer->GetTree();
+
+    // If the current tree is ACTIVE_TREE, then always generate a paired_layer.
+    // If current tree is PENDING_TREE, then only generate a paired_layer if
+    // there is no twin layer.
+    if (tree == ACTIVE_TREE) {
+      DCHECK(!twin_layer || twin_layer->GetTree() == PENDING_TREE);
+      paired_layer.active_layer = layer;
+      paired_layer.pending_layer = twin_layer;
+      paired_layers->push_back(paired_layer);
+    } else if (!twin_layer) {
+      paired_layer.active_layer = NULL;
+      paired_layer.pending_layer = layer;
+      paired_layers->push_back(paired_layer);
+    }
+  }
+}
+
 bool LayerTreeHostImpl::InitializeRenderer(
     scoped_ptr<OutputSurface> output_surface) {
   TRACE_EVENT0("cc", "LayerTreeHostImpl::InitializeRenderer");