Removed "compositor" child window that was created by the GPU process.

Removed "compositor" child window that was created by the GPU process.Removed the sync IPC that it used to ask the browser process to resize on Linux. Adapted windows to use the same mechanism.TEST=test webgl pages on windows (ANGLE and GL), linux and mac, run try job on windows, linux, mac. checkdeps failure look unrelated to patch.BUG=77536
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=83248

[apatrick_chromium, 2011-04-27 18:34:34]

http://codereview.chromium.org/6880218/diff/1025/content/browser/tab_contents...
File content/browser/tab_contents/tab_contents.cc (right):

http://codereview.chromium.org/6880218/diff/1025/content/browser/tab_contents...
content/browser/tab_contents/tab_contents.cc:2287:
rwh_view->SetSize(view_->GetContainerSize());
CreateRenderView calls GetCompositing, which assumes the size of the RWHV is
valid so I moved this up.

[jam, 2011-04-27 20:45:22]

some nits that I happened to see, and one question: so does this mean that there
are no HWNDs that are in the same hierarchy as the browser HWND in the gpu
process?  If so, out of curiosity, does that mean that the gpu memory is read
each time the browser wants to update a tab that has some 3d part in it?

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/gpu_process_h...
File chrome/browser/gpu_process_host_ui_shim.cc (right):

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/gpu_process_h...
chrome/browser/gpu_process_host_ui_shim.cc:264: render_view_id);
nit: looks like this can all fit on one line

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/renderer_host...
File chrome/browser/renderer_host/render_widget_host_view_win.cc (right):

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/renderer_host...
chrome/browser/renderer_host/render_widget_host_view_win.cc:472: 10000);
nit: use constant

[apatrick_chromium, 2011-04-27 21:08:26]

It depends what you mean by "in the GPU process". The window that the GPU
process presents to is created on the browser process' UI thread. The GPU
process has an HWND to this window for the purpose of presenting to it but it
does not create any child windows and it does not send WM_MESSAGES to any
windows. There is no GPU readback to system memory.

What D3D does with the HWND is out of our control. The long term plan on Vista
and Windows 7 is to not present to any HWND from the GPU process. At the that
point the GPU process will not need to know any HWNDs at all.

[nduca, 2011-04-27 21:12:57]

LGTM

I like setScheduled. :)

[jam, 2011-04-27 21:13:15]

When D3D is interacting with the HWND in the GPU process, does it ever block
on the parent HWND?  i.e. if the parent process is paused, can the GPU
process continue processing all the requests sent to it from renderers?

If so, then that's great.  If not, then we still have the deadlock issue.

On Wed, Apr 27, 2011 at 2:08 PM, <apatrick@chromium.org> wrote:

> It depends what you mean by "in the GPU process". The window that the GPU
> process presents to is created on the browser process' UI thread. The GPU
> process has an HWND to this window for the purpose of presenting to it but
> it
> does not create any child windows and it does not send WM_MESSAGES to any
> windows. There is no GPU readback to system memory.
>
> What D3D does with the HWND is out of our control. The long term plan on
> Vista
> and Windows 7 is to not present to any HWND from the GPU process. At the
> that
> point the GPU process will not need to know any HWNDs at all.
>
>
> http://codereview.chromium.org/6880218/
>

[apatrick_chromium, 2011-04-27 22:36:59]

On 2011/04/27 21:13:15, John Abd-El-Malek wrote:
> When D3D is interacting with the HWND in the GPU process, does it ever block
> on the parent HWND?  i.e. if the parent process is paused, can the GPU
> process continue processing all the requests sent to it from renderers?
> 
> If so, then that's great.  If not, then we still have the deadlock issue.
> 

The GPU process does a few things with the HWND: mainly call GetClientRect on it
and interact with it via IDirect3DSwapChain9 but it also attempts to subclass
the window when it creates a new surface (which now fails harmlessly because it
tries to do it from the wrong thread).

I did this experiment. I set a breakpoint on IDirect3DSwapChain9::Present and
let it stop there in the GPU process. I then "froze" the UI thread of the
browser process and stepped over the Present call and it displayed a new frame
without blocking. I also stepped over a GetClientRect while the browser's UI
thread was frozen and it did not block.

It rendered a second frame before the renderer process stopped requesting that
anything be rendered. The GPU process was sitting in its message loop waiting
for incoming IPCs at this point. There was no deadlock reported by the debugger.

I also simulated the case where the browser's UI thread was unresponsive while
trying to create a surface for the window. I set a breakpoint where ANGLE
attempts to subclass the window (SetWindowLong). SetWindowLong failed without
blocking and ANGLE recovered. When I "thawed" the browser's UI thread it
continued rendering normally.

Does that answer your question?

[apatrick_chromium, 2011-04-27 22:45:22]

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/gpu_process_h...
File chrome/browser/gpu_process_host_ui_shim.cc (right):

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/gpu_process_h...
chrome/browser/gpu_process_host_ui_shim.cc:264: render_view_id);
On 2011/04/27 20:45:22, John Abd-El-Malek wrote:
> nit: looks like this can all fit on one line

Done.

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/renderer_host...
File chrome/browser/renderer_host/render_widget_host_view_win.cc (right):

http://codereview.chromium.org/6880218/diff/1025/chrome/browser/renderer_host...
chrome/browser/renderer_host/render_widget_host_view_win.cc:472: 10000);
On 2011/04/27 20:45:22, John Abd-El-Malek wrote:
> nit: use constant

Done.

[jam, 2011-04-27 23:08:23]

On Wed, Apr 27, 2011 at 3:36 PM, <apatrick@chromium.org> wrote:

> On 2011/04/27 21:13:15, John Abd-El-Malek wrote:
>
>> When D3D is interacting with the HWND in the GPU process, does it ever
>> block
>> on the parent HWND?  i.e. if the parent process is paused, can the GPU
>> process continue processing all the requests sent to it from renderers?
>>
>
>  If so, then that's great.  If not, then we still have the deadlock issue.
>>
>
>
> The GPU process does a few things with the HWND: mainly call GetClientRect
> on it
> and interact with it via IDirect3DSwapChain9 but it also attempts to
> subclass
> the window when it creates a new surface (which now fails harmlessly
> because it
> tries to do it from the wrong thread).
>
> I did this experiment. I set a breakpoint on IDirect3DSwapChain9::Present
> and
> let it stop there in the GPU process. I then "froze" the UI thread of the
> browser process and stepped over the Present call and it displayed a new
> frame
> without blocking. I also stepped over a GetClientRect while the browser's
> UI
> thread was frozen and it did not block.
>
> It rendered a second frame before the renderer process stopped requesting
> that
> anything be rendered. The GPU process was sitting in its message loop
> waiting
> for incoming IPCs at this point. There was no deadlock reported by the
> debugger.
>
> I also simulated the case where the browser's UI thread was unresponsive
> while
> trying to create a surface for the window. I set a breakpoint where ANGLE
> attempts to subclass the window (SetWindowLong). SetWindowLong failed
> without
> blocking and ANGLE recovered. When I "thawed" the browser's UI thread it
> continued rendering normally.
>
> Does that answer your question?


yes, thanks for running this experiment, it's very good to know that this is
safe for sure.


>
>
> http://codereview.chromium.org/6880218/
>

[jam, 2011-04-27 23:11:49]

content lgtm, without  chrome/browser/gpu_process_host_ui_shim.*