cc: Set the mapped memory reclaim limit for the renderer compositor on Android

cc/trees/layer_tree_settings.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/trees/layer_tree_settings.h"
 
 #include <limits>
 
 #include "base/command_line.h"
 #include "base/logging.h"
@@ skipping 39 matching lines @@
       use_pinch_zoom_scrollbars(false),
       use_pinch_virtual_viewport(false),
       // At 256x256 tiles, 128 tiles cover an area of 2048x4096 pixels.
       max_tiles_for_interest_area(128),
       max_unused_resource_memory_percentage(100),
       highp_threshold_min(0),
       force_direct_layer_drawing(false),
       strict_layer_property_change_checking(false),
       use_map_image(false),
       compositor_name("ChromiumCompositor"),
-      ignore_root_layer_flings(false) {
+      ignore_root_layer_flings(false),
+      max_transfer_buffer_usage_bytes(0) {

[danakj, 2013/08/23 01:21:46]

Is there a reason for this to default to 0 in prod?

[kaanb, 2013/08/23 01:37:31]

We only initialize it to 0, it's always being assigned later when we create the
compositor. We also have a DCHECK in PBRWP to guarantee that it is always
assigned a valid value.

[danakj, 2013/08/23 01:53:07]

I'm just wondering cuz if you initialize it to something big here then you don't
have to do anything anywhere for tests. If there's some worry about prod places
not init'ing it or something?

   // TODO(danakj): Renable surface caching when we can do it more realiably.
   // crbug.com/170713
   cache_render_pass_contents = false;
 }
 
 LayerTreeSettings::~LayerTreeSettings() {}
 
 }  // namespace cc