Route IPC through browser when creating a viewable command buffer.

The communications path for creating a viewable command buffer used to be directly from the renderer (gpu_channel.cc) to the gpu process (gpu_channel.cc).  This patch makes the browser an intermediary:

- renderer (gpu_channel.cc) makes a synchronous request to the browser (picked up in renderer_message_filter.cc and forwarded to gpu_process_host.cc)

- browser (gpu_process_host.cc) makes an asynchronous request to the gpu process (picked up in gpu_thread.cc and forwarded to gpu_channel.cc) for the command buffer

- gpu process (gpu_thread.cc) sends an ACK with the route_id for the command buffer back to the browser (gpu_process_host.cc)

- browser (gpu_process_host.cc) sends a delayed reply back to the renderer
(gpu_channel_host.cc), which had blocked

There are several motivations for this patch:

- creating an onscreen command buffer requires a window to draw into (which is acquired/locked in the browser); by routing through the browser, we can acquire the get the window beforehand (thereby preventing a deadlock in some other work that I'm doing)

- we can eliminate several separate synchronous IPC messages for obtaining and releasing the window associated with drawing (I've tried to unify the different code paths for Linux, Windows, and Mac)

- in the future, we can have the browser allocate SHM for the command buffer and transfer buffers, allowing us to sandbox the gpu process

BUG=none
TEST=by hand on all 3 platforms, trybots

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

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

0 files changed, 0 insertions, 0 deletions