cc: Optimise shared raster tile handling in raster tile priority queue.

cc/resources/raster_tile_priority_queue.h

Index: cc/resources/raster_tile_priority_queue.h
diff --git a/cc/resources/raster_tile_priority_queue.h b/cc/resources/raster_tile_priority_queue.h
index bbfaafddef383a9e9f1e95a8f8815e8c26a8dfbd..3bca52babba391640bf62d43a48ca68a27b19041 100644
--- a/cc/resources/raster_tile_priority_queue.h
+++ b/cc/resources/raster_tile_priority_queue.h
@@ -30,9 +30,12 @@ class CC_EXPORT RasterTilePriorityQueue {
 
     PictureLayerImpl::LayerRasterTileIterator active_iterator;
     PictureLayerImpl::LayerRasterTileIterator pending_iterator;
+    bool has_both_layers;
 
+#if DCHECK_IS_ON

[reveman, 2014/09/05 17:08:32]

It would be better to always compile this so that it would work with
--enable-dchecks. Does having an always empty container here impact performance?

[USE eero AT chromium.org, 2014/09/08 14:08:17]

Done.
Not measurable impact.

     // TODO(vmpstr): Investigate removing this.

[reveman, 2014/09/05 17:08:32]

This TODO is not valid anymore, right? How about we update this to a comment
that explains what it is now used for?

[USE eero AT chromium.org, 2014/09/08 14:08:17]

Done.

     std::vector<Tile*> returned_shared_tiles;

[reveman, 2014/09/05 17:08:32]

Now that this is only used for debug checks, can we make it a std::set? Makes
the intent more clear and the code a bit cleaner, I think.

[USE eero AT chromium.org, 2014/09/08 14:08:17]

Yes, consumes more memory than std::vector but compared to the memory used by
the two layer raster tile iterators that is nothing.
If you say so.

+#endif
   };
 
   RasterTilePriorityQueue();