cc: Speed up CleanUpImageDecodeTasks a bit.

cc/resources/tile_manager.h

 // Copyright 2012 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.
 
 #ifndef CC_RESOURCES_TILE_MANAGER_H_
 #define CC_RESOURCES_TILE_MANAGER_H_
 
 #include <queue>
 #include <set>
 #include <vector>
@@ skipping 158 matching lines @@
   MemoryHistory::Entry memory_stats_from_last_assign_;
 
   RenderingStatsInstrumentation* rendering_stats_instrumentation_;
 
   bool did_initialize_visible_tile_;
 
   typedef base::hash_map<uint32_t, RasterWorkerPool::Task> PixelRefTaskMap;
   typedef base::hash_map<int, PixelRefTaskMap> LayerPixelRefTaskMap;
   LayerPixelRefTaskMap image_decode_tasks_;
 
+  typedef base::hash_map<int, int> LayerCountMap;

[tomhudson, 2013/09/04 18:38:34]

I assume we're using hash_map here instead of something directly addressable
because the range of layer IDs is large and very sparsely used?

[enne (OOO), 2013/09/04 18:45:24]

It really depends on the page.  Scrollbars in particular get attached and
detached a lot, burning through layer id space.  I think it would be unwise to
assume that layer ids are tightly packed or small in range.

[vmpstr, 2013/09/04 19:36:40]

Right.. I think it would be a waste to grow this to the max of all layer ids (in
order to be directly addressable. From the few pages I looked at, it seems that
we have a handful of layers, but their IDs can be in the range of >1000 (for
instance on sky.com)

+  LayerCountMap used_layer_counts_;
+
   RasterTaskCompletionStats update_visible_tiles_stats_;
 
   DISALLOW_COPY_AND_ASSIGN(TileManager);
 };
 
 }  // namespace cc
 
 #endif  // CC_RESOURCES_TILE_MANAGER_H_