content: Improve thread priority for raster threads.

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 1438e6a1d62fd0c2f2a8dc58981be72caede68dd..44f1fbea0870584687ace3d15ac2898b5ef2f806 100644
--- a/content/browser/gpu/compositor_util.cc
+++ b/content/browser/gpu/compositor_util.cc
@@ -188,13 +188,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/23 23:01:41]

I'm still skeptical of this though.  As I said earlier, I believe "any
additional raster threads should have niceness 10".  If I'm reading the patch
correctly, it looks like this change will add an extra thread with niceness 0 on
a 4-core device.

We have a ton of threads competing for our cores as it is.  I question that it's
a good idea to improve a raster benchmark by means of hogging more resources. 
Improving benchmarks by pure optimization is great, but this kind of change is
instead making a tradeoff.  Why do you believe it's the right tradeoff?  First
of all, can you point to a real-world site where I could experience the benefit
of the extra foreground raster thread on Android?

[reveman, 2016/02/24 17:08:54]

I'm not really looking to improve a specific benchmark or pushing for a specific
number of raster threads. I'd like to remove platform specific special cases.
Thanks to all the recent improvements to scheduling of raster work I'm hoping
that we can now use the same logic here on all platforms. ie. if it doesn't make
sense to use two raster threads on a 4 core Android device then that same logic
should apply to a 4 core arm chromebook or 4 core windows desktop.

The general use case for multiple raster threads is simply to allow chrome's
raster performance to scale on more powerful devices with multiple cores. More
precisely, not have idle cores when there's visible raster work to be done.
Pages with lots of images (especially animated images) tend to benefit the most
and we've seen good improvements on desktop and chromebook devices from this.

I'm OK changing the logic above to "num_raster_threads = num_processors / 4" if
we agree that that makes more sense. Or change the thread priority of raster
threads that run foreground work. The goal is to end up with logic that works
across all platforms.

I moved this num_raster_threads change to a different patch
(https://codereview.chromium.org/1733703002) as I'd rather not have the
otherwise really useful changes done by this patch blocked on this issue.

[aelias_OOO_until_Jul13, 2016/02/24 17:21:41]

Understood, that makes sense to me.  I've been continuing to mull it over on my
end, we can figure it out on the other patch.  Good idea on splitting it off
into another patch, it will also make the effect on the perf bots more obvious.

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