content: Allow multiple raster threads on Android.

content/browser/gpu/compositor_util.cc

Index: content/browser/gpu/compositor_util.cc
diff --git a/content/browser/gpu/compositor_util.cc b/content/browser/gpu/compositor_util.cc
index 88b2e7ae9c58162e02dd79fbbc2f4ab7cb918d81..cb8e8fd8be005ee9cfff3da22654a0f07da5c028 100644
--- a/content/browser/gpu/compositor_util.cc
+++ b/content/browser/gpu/compositor_util.cc
@@ -182,13 +182,6 @@ int NumberOfRendererRasterThreads() {
 
   int num_raster_threads = num_processors / 2;
 
-#if defined(OS_ANDROID)
-  // Limit the number of raster threads to 1 on Android.
-  // TODO(reveman): Remove this when we have a better mechanims to prevent
-  // pre-paint raster work from slowing down non-raster work. crbug.com/504515
-  num_raster_threads = 1;

[aelias_OOO_until_Jul13, 2016/02/26 03:12:02]

vmpstr@ and ericrk@ mentioned today they'd also prefer to hold off on increasing
the number of foreground threads on Android until their image decode work is
further along.  I'm open to revisiting this later when we have more confidence
in our task policy.

As long as the code that feeds tasks into the raster system is entirely sane, I
have no real grounds to object on raising the number of threads here, I'm just
not sure we're at that point quite yet.

-#endif
-
   const base::CommandLine& command_line =
       *base::CommandLine::ForCurrentProcess();