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, 0 insertions, 32 deletions

diff --git a/chrome/browser/browser_process_impl.cc b/chrome/browser/browser_process_impl.cc
index 3d7a073..7f8b7e9 100644
--- a/chrome/browser/browser_process_impl.cc
+++ b/chrome/browser/browser_process_impl.cc
@@ -117,7 +117,6 @@ BrowserProcessImpl::BrowserProcessImpl(const CommandLine& command_line)
       created_db_thread_(false),
       created_process_launcher_thread_(false),
       created_cache_thread_(false),
-      created_gpu_thread_(false),
       created_watchdog_thread_(false),
 #if defined(OS_CHROMEOS)
       created_web_socket_proxy_thread_(false),
@@ -240,7 +239,6 @@ BrowserProcessImpl::~BrowserProcessImpl() {
   // stopping the GPU thread. The GPU thread will close IPC channels to renderer
   // processes so this has to happen before stopping the IO thread.
   GpuProcessHostUIShim::DestroyAll();
-  gpu_thread_.reset();
 
   // Need to stop io_thread_ before resource_dispatcher_host_, since
   // io_thread_ may still deref ResourceDispatcherHost and handle resource
@@ -425,13 +423,6 @@ base::Thread* BrowserProcessImpl::cache_thread() {
   return cache_thread_.get();
 }
 
-base::Thread* BrowserProcessImpl::gpu_thread() {
-  DCHECK(CalledOnValidThread());
-  if (!created_gpu_thread_)
-    CreateGpuThread();
-  return gpu_thread_.get();
-}
-
 #if defined(USE_X11)
 base::Thread* BrowserProcessImpl::background_x11_thread() {
   DCHECK(CalledOnValidThread());
@@ -868,29 +859,6 @@ void BrowserProcessImpl::CreateCacheThread() {
   cache_thread_.swap(thread);
 }
 
-void BrowserProcessImpl::CreateGpuThread() {
-  DCHECK(!created_gpu_thread_ && !gpu_thread_.get());
-  created_gpu_thread_ = true;
-
-  scoped_ptr<base::Thread> thread(new BrowserThread(BrowserThread::GPU));
-
-  base::Thread::Options options;
-#if defined(OS_WIN)
-  // On Windows the GPU thread needs to pump the compositor child window's
-  // message loop. TODO(apatrick): make this an IO thread if / when we get rid
-  // of this child window. Unfortunately it might always be necessary for
-  // Windows XP because we cannot share the backing store textures between
-  // processes.
-  options.message_loop_type = MessageLoop::TYPE_UI;
-#else
-  options.message_loop_type = MessageLoop::TYPE_IO;
-#endif
-
-  if (!thread->StartWithOptions(options))
-    return;
-  gpu_thread_.swap(thread);
-}
-
 void BrowserProcessImpl::CreateWatchdogThread() {
   DCHECK(!created_watchdog_thread_ && watchdog_thread_.get() == NULL);
   created_watchdog_thread_ = true;