Fix gpu acceleration with --in-process-gpu and --single-process modes.

With recent changes that have moved gpu message handling in the browser to the IO thread (and moved the handling of messages between gpu and renderer, that are mediated by the browser, to GpuProcessHost), the routing for such messages was broken when running the gpu thread (rather than process).

The new approach is to always instantiate GpuProcessHost (even when running a gpu thread only) and have a real IPC channel between host and gpu thread. This makes the 'in-process' GPU code work similar to what the renderer does when running --single-process.

Note that --single-process mode is potentially still a bit fragile with this, since ChildProcess and ChildThread are currently written to only allow a single static instance in one process (it would be better to instantiate GpuProcess and RenderProcess simultaneously), so ambiguous calls to access e.g. the main thread are possible.

Review URL: http://codereview.chromium.org/7054005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@86958 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 5 insertions, 1 deletions

diff --git a/content/gpu/gpu_child_thread.cc b/content/gpu/gpu_child_thread.cc
index 8612a66..d3e6e94 100644
--- a/content/gpu/gpu_child_thread.cc
+++ b/content/gpu/gpu_child_thread.cc
@@ -116,7 +116,11 @@ bool GpuChildThread::OnControlMessageReceived(const IPC::Message& msg) {
 }
 
 void GpuChildThread::OnInitialize() {
-  logging::SetLogMessageHandler(GpuProcessLogMessageHandler);
+  // We don't need to pipe log messages if we are running the GPU thread in
+  // the browser process.
+  if (!CommandLine::ForCurrentProcess()->HasSwitch(switches::kSingleProcess) &&
+      !CommandLine::ForCurrentProcess()->HasSwitch(switches::kInProcessGPU))
+    logging::SetLogMessageHandler(GpuProcessLogMessageHandler);
 
   // Load the GL implementation and locate the bindings before starting the GPU
   // watchdog because this can take a lot of time and the GPU watchdog might