content: Add switch to enable checker-imaging.

content/renderer/gpu/render_widget_compositor.cc

Index: content/renderer/gpu/render_widget_compositor.cc
diff --git a/content/renderer/gpu/render_widget_compositor.cc b/content/renderer/gpu/render_widget_compositor.cc
index a7642b16027d907674c1efd874bea5ea68ff89e5..562a445d1dfe6c871887655bcd4af98de4b44ce0 100644
--- a/content/renderer/gpu/render_widget_compositor.cc
+++ b/content/renderer/gpu/render_widget_compositor.cc
@@ -240,11 +240,15 @@ std::unique_ptr<cc::LayerTreeHost> RenderWidgetCompositor::CreateLayerTreeHost(
   params.main_task_runner = deps->GetCompositorMainThreadTaskRunner();
   params.mutator_host = mutator_host;
   if (base::TaskScheduler::GetInstance()) {
+    // The image worker thread needs to allow waiting since it makes discardable
+    // shared memory allocations which need to make synchronous calls to the
+    // IO thread.
     params.image_worker_task_runner = base::CreateSequencedTaskRunnerWithTraits(
         base::TaskTraits()
             .WithPriority(base::TaskPriority::BACKGROUND)
             .WithShutdownBehavior(
-                base::TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN));
+                base::TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN)
+            .WithBaseSyncPrimitives());

[enne (OOO), 2017/02/25 00:09:12]

How did this work before?

[Khushal, 2017/02/25 00:14:01]

It didn't, nobody uses this worker yet. I think on the raster threads, we allow
waiting, which is where this happens right now.
https://cs.chromium.org/chromium/src/content/renderer/categorized_worker_pool...

[enne (OOO), 2017/02/25 00:16:30]

Oh right right, this was all within cc in previous patches.  Oops, silly
question.

Hmm.  Do we make synchronous calls to the image worker thread at this point?
Just wondering about potential deadlock.  Can this sort of thing (where thread
can make synchronous calls to, who can call it synchronously, etc) be better
documented, maybe on the init params itself or elsewhere?

[Khushal, 2017/02/25 02:48:03]

We do make sync calls to the worker from only the compositor thread, for
flushing pending tasks. But I think we should be fine. The worker only waits on
the IO thread, and thats not any different from what already happens with the
raster worker threads.

I can add a comment on the InitParams in cc that specifies that the compositor
thread can make sync calls to the worker, in addition to the comment here?

While I was here, I was also wondering why we use shared memory for the
discardable memory allocation. This happens when we are allocating memory for
the decode, which is used in the renderer only right?

[enne (OOO), 2017/02/27 20:45:50]

Yeah, I think making a comment that this thread behaves like the raster worker
threads would be fine.

I'm less clear on what's going on with the discardable stuff here.

[Khushal, 2017/02/27 22:57:05]

Done. Thanks!

I was curious and stumbled upon a doc which explains the discardable shared
memory design:
https://docs.google.com/document/d/1aNdOF_72_eG2KUM_z9kHdbT_fEupWhaDALaZs5D8I....

   }
   if (!is_threaded) {
     // Single-threaded layout tests.
@@ -273,6 +277,9 @@ cc::LayerTreeSettings RenderWidgetCompositor::GenerateLayerTreeSettings(
   settings.main_frame_before_activation_enabled =
       cmd.HasSwitch(cc::switches::kEnableMainFrameBeforeActivation);
 
+  settings.enable_checker_imaging =
+      cmd.HasSwitch(cc::switches::kEnableCheckerImaging);
+
   // TODO(danakj): This should not be a setting O_O; it should change when the
   // device scale factor on LayerTreeHost changes.
   settings.default_tile_size =