cc: Fix DCHECK in tile manager queue perftests.

cc/resources/tile_manager_perftest.cc

Index: cc/resources/tile_manager_perftest.cc
diff --git a/cc/resources/tile_manager_perftest.cc b/cc/resources/tile_manager_perftest.cc
index 69bdaa468056cf1d1cefd28d9b5af8a0edd27b8b..7892f0fecdf1b70e8e7c9c841cb047a1e4498c52 100644
--- a/cc/resources/tile_manager_perftest.cc
+++ b/cc/resources/tile_manager_perftest.cc
@@ -351,26 +351,26 @@ TEST_F(TileManagerPerfTest, ManageTiles) {
 }
 
 TEST_F(TileManagerPerfTest, RasterTileQueueConstruct) {
-  SetupDefaultTrees(gfx::Size(10000, 10000));
+  SetupDefaultTrees(gfx::Size(1000, 1000));

[reveman, 2014/07/24 19:52:58]

What's the motivation for using this specific size? Does it closer match what is
used in the wild?

[vmpstr, 2014/07/24 19:58:21]

The problem is really just creating all the tiles for 100 layers with tree being
10000x10000. It takes about 40 seconds just to build that in a debug build on
linux. This change is just so it doesn't time out on the bots. The current
approach creates everything fairly quickly (1-2 seconds).

[reveman, 2014/07/24 20:14:37]

Acknowledged.

   active_root_layer_->CreateDefaultTilingsAndTiles();
   pending_root_layer_->CreateDefaultTilingsAndTiles();
 
   RunRasterQueueConstructTest("2");
 
   for (int i = 0; i < 8; ++i) {
-    PictureLayerTiling* tiling = active_root_layer_->AddTiling(i * 0.3f);
+    PictureLayerTiling* tiling = active_root_layer_->AddTiling(1.3f + i * 0.3f);
     tiling->CreateAllTilesForTesting();
   }
 
   RunRasterQueueConstructTest("10");
 
-  for (int i = 0; i < 90; ++i) {
+  for (int i = 0; i < 40; ++i) {
     PictureLayerTiling* tiling =
-        active_root_layer_->AddTiling(1.0f + i * 0.03f);
+        active_root_layer_->AddTiling(2.03f + i * 0.03f);
     tiling->CreateAllTilesForTesting();
   }
 
-  RunRasterQueueConstructTest("100");
+  RunRasterQueueConstructTest("50");

[reveman, 2014/07/24 19:52:58]

why not 100? is the overlap in scales between the first 10 and last 40
intentional and necessary? seems like it would be a bit easier to make sure they
don't overlap if that's not the case..

[vmpstr, 2014/07/24 19:58:21]

I don't think there's overlap? I mean the fix was here against add tiling adding
a scale that already exists, so an overlap would dcheck.

[reveman, 2014/07/24 20:14:37]

I meant overlap in the sense that:

1.3f + i * 0.3f, where i=7 is greater than
2.03f + i * 0.03f, where i=0, which is greater than
1.3f + i * 0.3f, where i=0

just makes it harder to see if the scales might collide compared to something
simple as:

1.3f + num_tilings * 0.3f in both cases

Still curious to why you changed it from 100 to 50. Is that part of fixing
timeout issues?

[vmpstr, 2014/07/24 21:37:36]

Ah I see what you mean. That is better, I've changed it.
Yes, this is due to timeouts...

 }
 
 TEST_F(TileManagerPerfTest, RasterTileQueueConstructAndIterate) {