Moved creation of GPU transfer buffers into the browser process....

Moved creation of GPU transfer buffers into the browser process.

Transfer buffer creation was previously done in the GPU process. This is one step required to sandbox the GPU process.

Rather than the GPU process opening a renderer process's handle by PID, which can't been done when sandboxed on Windows, the browser process passes the handle to the GPU process via the renderer process.

TEST=try
BUG=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=75980

[Ken Russell (switch to Gerrit), 2011-02-24 19:48:47]

LGTM with a few comment issues addressed.

http://codereview.chromium.org/6557006/diff/9002/chrome/browser/gpu_process_h...
File chrome/browser/gpu_process_host.cc (right):

http://codereview.chromium.org/6557006/diff/9002/chrome/browser/gpu_process_h...
chrome/browser/gpu_process_host.cc:181: // Send the GPU process handle to the UI
thread before it has to any
Remove "any" at end of line.

http://codereview.chromium.org/6557006/diff/9002/chrome/common/gpu_messages_i...
File chrome/common/gpu_messages_internal.h (right):

http://codereview.chromium.org/6557006/diff/9002/chrome/common/gpu_messages_i...
chrome/common/gpu_messages_internal.h:183: // renderer passes a process handle
to the GPU process, which gives it the
I found this really confusing to understand. I think a simple change to "The
renderer passes its process handle..." would help. Also, perhaps "gives the GPU
process the ability to map handles from the renderer process".

http://codereview.chromium.org/6557006/diff/9002/chrome/common/gpu_messages_i...
chrome/common/gpu_messages_internal.h:187: base::ProcessHandle /*
gpu_renderer_process */)
I found the naming convention of "gpu_renderer_process" throughout this CL
confusing, at least until finding another example ("browser_gpu_process"). Could
a different convention be used? How about "renderer_process_for_gpu"?

http://codereview.chromium.org/6557006/diff/9002/chrome/renderer/gpu_channel_...
File chrome/renderer/gpu_channel_host.cc (right):

http://codereview.chromium.org/6557006/diff/9002/chrome/renderer/gpu_channel_...
chrome/renderer/gpu_channel_host.cc:34: // Notify the GPU process of out process
handle. This gives it the ability
out -> our

http://codereview.chromium.org/6557006/diff/9002/content/browser/renderer_hos...
File content/browser/renderer_host/gpu_message_filter.cc (right):

http://codereview.chromium.org/6557006/diff/9002/content/browser/renderer_hos...
content/browser/renderer_host/gpu_message_filter.cc:74: base::ProcessHandle
browser_gpu_process,
Perhaps "gpu_process_for_browser"?

[piman, 2011-02-25 04:13:48]

http://codereview.chromium.org/6557006/diff/9002/chrome/renderer/command_buff...
File chrome/renderer/command_buffer_proxy.cc (right):

http://codereview.chromium.org/6557006/diff/9002/chrome/renderer/command_buff...
chrome/renderer/command_buffer_proxy.cc:145: base::SharedMemory
shared_memory(handle, false);
This is wrong on posix.
When sending the handle (base::FileDescriptor), it will always be destroyed
whether Send succeeds or not.
The side effect of this is that the fd gets closed twice - once when this goes
out of scope, and once again when the message is sent on the IPC thread. The
second close may close another arbitrary fd that got open in the mean time with
the same number.