cc: Remove the unused compositor thread variable and interface.

content/browser/compositor/gpu_process_transport_factory.cc

Index: content/browser/compositor/gpu_process_transport_factory.cc
diff --git a/content/browser/compositor/gpu_process_transport_factory.cc b/content/browser/compositor/gpu_process_transport_factory.cc
index b9f65d5c01812dd8c685342746897f70254175ac..75d63566b160f9331fffd8c2277208ba4f51a56f 100644
--- a/content/browser/compositor/gpu_process_transport_factory.cc
+++ b/content/browser/compositor/gpu_process_transport_factory.cc
@@ -187,9 +187,7 @@ void GpuProcessTransportFactory::EstablishedGpuChannel(
 
   if (context_provider.get()) {
     scoped_refptr<base::SingleThreadTaskRunner> compositor_thread_task_runner =
-        GetCompositorMessageLoop();
-    if (!compositor_thread_task_runner.get())
-      compositor_thread_task_runner = base::MessageLoopProxy::current();
+        base::MessageLoopProxy::current();
 
     // Here we know the GpuProcessHost has been set up, because we created a
     // context.
@@ -238,10 +236,9 @@ void GpuProcessTransportFactory::EstablishedGpuChannel(
   }
 
   if (!context_provider.get()) {
-    if (compositor_thread_.get()) {
-      LOG(FATAL) << "Failed to create UI context, but can't use software"
-                    " compositing with browser threaded compositing. Aborting.";
-    }
+#if defined(OS_CHROMEOS)
+    NOTREACHED() << "Shouldn't use software compositing on ChromeOS.";

[no sievers, 2015/02/20 02:14:31]

So with threaded compositing we would get crash reports previously on CrOS for
reaching this. After switching to single-threaded compositing, we then allowed
this to fall back to software here even on CrOS?
I guess we now still do allow fallback to sw in release builds, but not debug
builds. Although we wouldn't run the unittests anymore with this patch, so
things might break. Should we always totally explode here then maybe?

And do you want to DCHECK(!create_software_renderer) for CrOS above?

[danakj, 2015/02/20 03:32:08]

ya we did because of those tests which I just fixed in this CL to not software
composite on CrOS.
Ya good idea, I'll LOG(FATAL) back again.
It seems a little bit overkill maybe? I could if you feel strongly.

+#endif
 
     scoped_ptr<SoftwareBrowserCompositorOutputSurface> surface(
         new SoftwareBrowserCompositorOutputSurface(
@@ -261,7 +258,6 @@ void GpuProcessTransportFactory::EstablishedGpuChannel(
         context_provider, data->surface_id, &output_surface_map_,
         compositor->vsync_manager(),
         CreateOverlayCandidateValidator(compositor->widget()), GL_RGB,
-        compositor_thread_ != nullptr,
         BrowserGpuMemoryBufferManager::current()));
   }
 #endif
@@ -285,10 +281,8 @@ scoped_refptr<ui::Reflector> GpuProcessTransportFactory::CreateReflector(
   PerCompositorData* data = per_compositor_data_[source];
   DCHECK(data);
 
-  data->reflector = new ReflectorImpl(source,
-                                      target,
-                                      &output_surface_map_,
-                                      GetCompositorMessageLoop(),
+  data->reflector = new ReflectorImpl(source, target, &output_surface_map_,
+                                      nullptr,  // Compositor message loop.
                                       data->surface_id);
   return data->reflector;
 }
@@ -347,12 +341,6 @@ ui::ContextFactory* GpuProcessTransportFactory::GetContextFactory() {
   return this;
 }
 
-base::MessageLoopProxy* GpuProcessTransportFactory::GetCompositorMessageLoop() {
-  if (!compositor_thread_)
-    return NULL;
-  return compositor_thread_->message_loop_proxy().get();
-}
-
 gfx::GLSurfaceHandle GpuProcessTransportFactory::GetSharedSurfaceHandle() {
   gfx::GLSurfaceHandle handle = gfx::GLSurfaceHandle(
       gfx::kNullPluginWindow, gfx::NULL_TRANSPORT);