Decouple browser-specific GPU IPC messages from GPU service IPCs

Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}

Committed: https://crrev.com/a660ce06aa37e51a849f68d01d27ce3f36cbe626
Cr-Commit-Position: refs/heads/master@{#377496}

[Fady Samuel, 2016-02-18 03:10:03]

Description was changed from

==========
[WIP] Move to gpu_browser_messages.h

BUG=
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily make sense in Mus+Ash. This CL
decouples browser messages from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_browser_messages.h file.
2. Browser channel message handling is moved entirely to GpuChildThread.
3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

Move browser-
BUG=
==========

[Fady Samuel, 2016-02-18 03:10:31]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily make sense in Mus+Ash. This CL
decouples browser messages from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_browser_messages.h file.
2. Browser channel message handling is moved entirely to GpuChildThread.
3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

Move browser-
BUG=
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_browser_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

BUG=
==========

[Fady Samuel, 2016-02-18 03:12:45]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_browser_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

BUG=
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_browser_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[Fady Samuel, 2016-02-18 03:13:31]

fsamuel@chromium.org changed reviewers:
+ sievers@chromium.org

[Fady Samuel, 2016-02-18 03:13:31]

Hi Daniel,

I was hoping you could please give me your thoughts on this patch. Once you're
happy with it, I'd like to pass it along to piman@ to also sign off on it.
Thanks! :-)

Fady

[piman, 2016-02-18 03:40:23]

piman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2016-02-18 03:40:24]

https://codereview.chromium.org/1711533002/diff/40001/content/common/gpu/gpu_...
File content/common/gpu/gpu_browser_messages.h (right):

https://codereview.chromium.org/1711533002/diff/40001/content/common/gpu/gpu_...
content/common/gpu/gpu_browser_messages.h:30: #define IPC_MESSAGE_START
GpuMsgStart
Drive-by: you need a different (new) enum value here. They come from
ipc/ipc_message_start.h

A message id is formed from the combination of this enum and the line number in
this file, so if you use the same enum in 2 files, you may accidentally reuse a
message id, potentially causing havok.

[Fady Samuel, 2016-02-18 04:02:08]

On 2016/02/18 03:40:24, piman wrote:
>
https://codereview.chromium.org/1711533002/diff/40001/content/common/gpu/gpu_...
> File content/common/gpu/gpu_browser_messages.h (right):
> 
>
https://codereview.chromium.org/1711533002/diff/40001/content/common/gpu/gpu_...
> content/common/gpu/gpu_browser_messages.h:30: #define IPC_MESSAGE_START
> GpuMsgStart
> Drive-by: you need a different (new) enum value here. They come from
> ipc/ipc_message_start.h
> 
> A message id is formed from the combination of this enum and the line number
in
> this file, so if you use the same enum in 2 files, you may accidentally reuse
a
> message id, potentially causing havok.

Thanks Anotine for catching that! I completely forgot about that! I'll take care
of it in my next patch!

[Fady Samuel, 2016-02-18 04:48:12]

Thanks Again Antoine! Please talk a look, Daniel! Thanks! :-)

https://codereview.chromium.org/1711533002/diff/40001/content/common/gpu/gpu_...
File content/common/gpu/gpu_browser_messages.h (right):

https://codereview.chromium.org/1711533002/diff/40001/content/common/gpu/gpu_...
content/common/gpu/gpu_browser_messages.h:30: #define IPC_MESSAGE_START
GpuMsgStart
On 2016/02/18 03:40:24, piman wrote:
> Drive-by: you need a different (new) enum value here. They come from
> ipc/ipc_message_start.h
> 
> A message id is formed from the combination of this enum and the line number
in
> this file, so if you use the same enum in 2 files, you may accidentally reuse
a
> message id, potentially causing havok.

Done.

[Fady Samuel, 2016-02-18 14:24:47]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-18 14:25:01]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/80001

[commit-bot: I haz the power, 2016-02-18 14:41:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-18 14:41:24]

Dry run: Try jobs failed on following builders:
  cast_shell_android on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[no sievers, 2016-02-19 00:19:24]

This is actually a nice cleanup since it makes it clearer what the direction of
communication is.

Do we really need to rename GpuHostMsg_* and GpuMsg*?

I find it slightly confusing that GpuBrowserMsg_ is a message from and not to
the browser, while GpuBrowserHost just sounds confusing. Could we just leave
them as is (GpuMsg/GpuHostMsg)?

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager.cc:223: void
GpuChannelManager::LoadedShader(const std::string& program_proto) {
nit: PopulateShaderCache(), CacheShaderProgram() maybe?

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager.cc:255: void
GpuChannelManager::ClearAllChannels() {
nit: DestroyAllChannels?

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager_delegate.h:16: virtual void
CacheShader(int32_t client_id,
nit: Maybe this could be StoreShaderToDisk() (you can add a comment that this is
for the embedder to provide persistent storage and the embedder is further
expected to repopulate the in-memory cache through the respective
GpuChannelManager API.)

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager_delegate.h:23: virtual void
DestroyChannel(int client_id) = 0;
nit: how about DidDestroyChannel()?

https://codereview.chromium.org/1711533002/diff/80001/ipc/ipc_message_start.h
File ipc/ipc_message_start.h (right):

https://codereview.chromium.org/1711533002/diff/80001/ipc/ipc_message_start.h...
ipc/ipc_message_start.h:24: GpuMsgStart,
This would be unused with your current patch.

[Fady Samuel, 2016-02-19 01:13:11]

PTAL Daniel! Unfortunately, I can't keep GpuMsg/GpuHostMsg with this move
because the macros use the line number within a file as piman@ mentioned, and I
do agree GpuBrowserMsg/GpuBrowserHostMsg is a bit confusing. Another name is
welcome :-)

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager.cc:223: void
GpuChannelManager::LoadedShader(const std::string& program_proto) {
On 2016/02/19 00:19:24, sievers wrote:
> nit: PopulateShaderCache(), CacheShaderProgram() maybe?

Done.

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager.cc:255: void
GpuChannelManager::ClearAllChannels() {
On 2016/02/19 00:19:24, sievers wrote:
> nit: DestroyAllChannels?

Done.

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager_delegate.h:16: virtual void
CacheShader(int32_t client_id,
On 2016/02/19 00:19:24, sievers wrote:
> nit: Maybe this could be StoreShaderToDisk() (you can add a comment that this
is
> for the embedder to provide persistent storage and the embedder is further
> expected to repopulate the in-memory cache through the respective
> GpuChannelManager API.)

Done.

https://codereview.chromium.org/1711533002/diff/80001/content/common/gpu/gpu_...
content/common/gpu/gpu_channel_manager_delegate.h:23: virtual void
DestroyChannel(int client_id) = 0;
On 2016/02/19 00:19:24, sievers wrote:
> nit: how about DidDestroyChannel()?

Done.

https://codereview.chromium.org/1711533002/diff/80001/ipc/ipc_message_start.h
File ipc/ipc_message_start.h (right):

https://codereview.chromium.org/1711533002/diff/80001/ipc/ipc_message_start.h...
ipc/ipc_message_start.h:24: GpuMsgStart,
On 2016/02/19 00:19:24, sievers wrote:
> This would be unused with your current patch.

No actually. GpuMsg is still used GpuMsg/GpuHostMsg IPCs still exist. I've just
teased out browser messages.

[Fady Samuel, 2016-02-19 01:13:25]

PTAL Daniel!

[Fady Samuel, 2016-02-19 13:54:28]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-19 13:56:39]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/100001

[commit-bot: I haz the power, 2016-02-19 14:08:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-19 14:08:31]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_chromium_gn_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)
  android_chromium_gn_compile_rel on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_chro...)
  android_clang_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  cast_shell_android on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromeos_x86-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_clobber_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_gn_chromeos_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win8_chromium_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Mark Dittmer, 2016-02-19 14:28:07]

markdittmer@chromium.org changed reviewers:
+ markdittmer@chromium.org

[Mark Dittmer, 2016-02-19 14:28:08]

https://codereview.chromium.org/1711533002/diff/100001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/100001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_delegate.h:1: // Copyright 2015 The
Chromium Authors. All rights reserved.
nit: it's 2016. Possibly elsewhere too.

[Fady Samuel, 2016-02-19 18:39:28]

I've restored GpuMsg/GpuHostMsg. PTAL Daniel!

[Fady Samuel, 2016-02-19 18:40:35]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[Fady Samuel, 2016-02-19 18:48:12]

Addressed Mark's nit.

https://codereview.chromium.org/1711533002/diff/100001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/100001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_delegate.h:1: // Copyright 2015 The
Chromium Authors. All rights reserved.
On 2016/02/19 14:28:08, Mark Dittmer wrote:
> nit: it's 2016. Possibly elsewhere too.

Done.

[no sievers, 2016-02-19 19:46:24]

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_browser_messages.h (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_browser_messages.h:6: // for a much smaller-than-usual
include guard section.
nit: how about we call this file gpu_host_messages.h to avoid the notion of the
browser here?

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.h (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:175: IPC::SyncChannel* const channel_;
You can remove |channel_| now.

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_unittest.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_unittest.cc:12: #include
"content/common/gpu/gpu_messages.h"
...and we don't need to include gpu_messages.h anymore :)

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_test_common.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_test_common.cc:66: sink_(sink) {}
Isn't the |sink_| unused now too with everything going through the delegate?

https://codereview.chromium.org/1711533002/diff/140001/content/gpu/gpu_child_...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:56: // on
nit: formatting

https://codereview.chromium.org/1711533002/diff/140001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:343: new GpuChannelManager(this, channel(),
watchdog_thread_.get(),
no need to pass channel() anymore

[Fady Samuel, 2016-02-19 20:33:31]

PTAL Daniel! :-)

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_browser_messages.h (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_browser_messages.h:6: // for a much smaller-than-usual
include guard section.
On 2016/02/19 19:46:23, sievers wrote:
> nit: how about we call this file gpu_host_messages.h to avoid the notion of
the
> browser here?

Done.

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.h (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:175: IPC::SyncChannel* const channel_;
On 2016/02/19 19:46:23, sievers wrote:
> You can remove |channel_| now.

Done.

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_unittest.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_unittest.cc:12: #include
"content/common/gpu/gpu_messages.h"
On 2016/02/19 19:46:23, sievers wrote:
> ...and we don't need to include gpu_messages.h anymore :)

Done.

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_test_common.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_test_common.cc:66: sink_(sink) {}
On 2016/02/19 19:46:23, sievers wrote:
> Isn't the |sink_| unused now too with everything going through the delegate?

It is used by the GpuChannel.

https://codereview.chromium.org/1711533002/diff/140001/content/gpu/gpu_child_...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:56: // on
On 2016/02/19 19:46:23, sievers wrote:
> nit: formatting

Done.

https://codereview.chromium.org/1711533002/diff/140001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:343: new GpuChannelManager(this, channel(),
watchdog_thread_.get(),
On 2016/02/19 19:46:23, sievers wrote:
> no need to pass channel() anymore

Done.

[Fady Samuel, 2016-02-19 20:49:30]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-19 20:50:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/160001

[commit-bot: I haz the power, 2016-02-19 21:06:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-19 21:06:44]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[no sievers, 2016-02-19 21:08:29]

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_test_common.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_test_common.cc:66: sink_(sink) {}
On 2016/02/19 20:33:30, Fady Samuel wrote:
> On 2016/02/19 19:46:23, sievers wrote:
> > Isn't the |sink_| unused now too with everything going through the delegate?
> 
> It is used by the GpuChannel.

Ah there is some confusion between the channels and everything goes through one
sink in the tests. It would probably make a bit more sense for each
TestGpuChannel to have a sink and then change the two call sites in
GpuChannelTest::HandleMessage() to call channel->sink() instead.

[Fady Samuel, 2016-02-20 02:53:08]

PTAL Daniel!

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_test_common.cc (right):

https://codereview.chromium.org/1711533002/diff/140001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_test_common.cc:66: sink_(sink) {}
On 2016/02/19 21:08:29, sievers wrote:
> On 2016/02/19 20:33:30, Fady Samuel wrote:
> > On 2016/02/19 19:46:23, sievers wrote:
> > > Isn't the |sink_| unused now too with everything going through the
delegate?
> > 
> > It is used by the GpuChannel.
> 
> Ah there is some confusion between the channels and everything goes through
one
> sink in the tests. It would probably make a bit more sense for each
> TestGpuChannel to have a sink and then change the two call sites in
> GpuChannelTest::HandleMessage() to call channel->sink() instead.

Done.

[Fady Samuel, 2016-02-20 02:53:16]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-20 02:54:50]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/180001

[commit-bot: I haz the power, 2016-02-20 03:11:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-20 03:11:30]

Dry run: Try jobs failed on following builders:
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Fady Samuel, 2016-02-20 04:50:25]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-20 04:51:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/200001

[commit-bot: I haz the power, 2016-02-20 05:20:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-20 05:20:40]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Fady Samuel, 2016-02-20 14:57:47]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-20 14:58:01]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/220001

[Fady Samuel, 2016-02-20 15:35:13]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-20 15:35:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/240001

[Fady Samuel, 2016-02-20 15:47:09]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_browser_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[Fady Samuel, 2016-02-20 15:47:19]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement and alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[Fady Samuel, 2016-02-20 16:00:53]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[Fady Samuel, 2016-02-20 16:01:12]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making GpuChildThread a
GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[Fady Samuel, 2016-02-20 16:01:31]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[commit-bot: I haz the power, 2016-02-20 16:46:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-20 16:46:14]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2016-02-22 16:11:48]

Hi Daniel! 

All the bots are happy! Yay! It took more work than I expected to get to that
stage. PTAL!

Fady

[no sievers, 2016-02-22 21:57:42]

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.cc:125: int32_t routing_id,
If this doesn't use AddRoute() can you rename it?

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.h (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:25: #include "ipc/ipc_sender.h"
unused ipc/ includes, yay...
you need to fwd declare IPC::ChannelHandle though.

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:84: const GpuChannelManagerDelegate*
delegate() const { return delegate_; }
nit: why two getters? you just need one getter that's const wrt GpuChannel
(const method), right?

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_delegate.h:48: // storage. The embedder
is expected tor epopulate the in-memory cache through
nit: typo 'tor epopulate'

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
File content/common/gpu/image_transport_surface.cc (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
content/common/gpu/image_transport_surface.cc:62: route_id_ =
manager_->GenerateRouteID();
It doesn't seem right to use GenerateRouteID() here.
Luckily, on Mac the PluginWindowHandle is the surface_id, so we can use that.

But can you move all of this out of ImageTransportHelper, since it's only used
on Mac nowadays, and so that it's obvious what we're doing here with the handle?
(I think it just means moving the Add/RemoveITS() call site from here and into
ImageTransportSurfaceOverlayMac, and removing some code here.)

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
File content/common/gpu/image_transport_surface.h (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
content/common/gpu/image_transport_surface.h:113: ~ImageTransportHelper();
it's still overriden

[Fady Samuel, 2016-02-23 04:45:27]

PTAL Daniel!

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.cc:125: int32_t routing_id,
On 2016/02/22 21:57:42, sievers wrote:
> If this doesn't use AddRoute() can you rename it?

Done.

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.h (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:25: #include "ipc/ipc_sender.h"
On 2016/02/22 21:57:42, sievers wrote:
> unused ipc/ includes, yay...
> you need to fwd declare IPC::ChannelHandle though.

Done.

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:84: const GpuChannelManagerDelegate*
delegate() const { return delegate_; }
On 2016/02/22 21:57:42, sievers wrote:
> nit: why two getters? you just need one getter that's const wrt GpuChannel
> (const method), right?

This is a pattern we've been using in Mus, but it's not used throughout Chrome
so I'm reverting to the single const method accessor.

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_delegate.h:48: // storage. The embedder
is expected tor epopulate the in-memory cache through
On 2016/02/22 21:57:42, sievers wrote:
> nit: typo 'tor epopulate'

Done.

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
File content/common/gpu/image_transport_surface.cc (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
content/common/gpu/image_transport_surface.cc:62: route_id_ =
manager_->GenerateRouteID();
On 2016/02/22 21:57:42, sievers wrote:
> It doesn't seem right to use GenerateRouteID() here.
> Luckily, on Mac the PluginWindowHandle is the surface_id, so we can use that.
> 
> But can you move all of this out of ImageTransportHelper, since it's only used
> on Mac nowadays, and so that it's obvious what we're doing here with the
handle?
> (I think it just means moving the Add/RemoveITS() call site from here and into
> ImageTransportSurfaceOverlayMac, and removing some code here.)
> 

I've filed a bug to move code out of ImageTransportHelper:
https://bugs.chromium.org/p/chromium/issues/detail?id=588958

I've set it as a blocker to make sure it gets done, but I'd like to do it in a
separate CL so this CL doesn't continue to balloon further. I'm now doing
routing based on the surface_id.

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
File content/common/gpu/image_transport_surface.h (right):

https://codereview.chromium.org/1711533002/diff/240001/content/common/gpu/ima...
content/common/gpu/image_transport_surface.h:113: ~ImageTransportHelper();
On 2016/02/22 21:57:42, sievers wrote:
> it's still overriden

I can't. SupportsWeakPtr doesn't have a virtual destructor so I can't override
it here.

[Fady Samuel, 2016-02-23 04:45:38]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-23 04:46:04]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/260001

[commit-bot: I haz the power, 2016-02-23 05:57:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-23 05:57:43]

Dry run: This issue passed the CQ dry run.

[no sievers, 2016-02-23 21:50:12]

lgtm

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.cc:123: void
GpuChannelManager::AddImageTransportSurface(
nit: ifdef mac

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.h (right):

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:105: #if defined(OS_MACOSX)
nit: Add/Remove is also only used on Mac.

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:173: IDMap<ImageTransportHelper>
image_transport_map_;
nit: mac only here too

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_delegate.h:13: struct GPUMemoryUmaStats;
you are missing a few fwd declarations here: GURL, IPC::ChannelHandle,
gpu:error:ContextLostReason.

[Fady Samuel, 2016-02-23 22:43:43]

PTAL Antoine! :-)

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.cc (right):

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.cc:123: void
GpuChannelManager::AddImageTransportSurface(
On 2016/02/23 21:50:12, sievers wrote:
> nit: ifdef mac

Done.

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager.h (right):

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:105: #if defined(OS_MACOSX)
On 2016/02/23 21:50:12, sievers wrote:
> nit: Add/Remove is also only used on Mac.

Done.

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager.h:173: IDMap<ImageTransportHelper>
image_transport_map_;
On 2016/02/23 21:50:12, sievers wrote:
> nit: mac only here too

Done.

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
File content/common/gpu/gpu_channel_manager_delegate.h (right):

https://codereview.chromium.org/1711533002/diff/260001/content/common/gpu/gpu...
content/common/gpu/gpu_channel_manager_delegate.h:13: struct GPUMemoryUmaStats;
On 2016/02/23 21:50:12, sievers wrote:
> you are missing a few fwd declarations here: GURL, IPC::ChannelHandle,
> gpu:error:ContextLostReason.
> 

Done.

[Fady Samuel, 2016-02-23 22:44:01]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-23 22:48:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/300001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/300001

[commit-bot: I haz the power, 2016-02-23 23:13:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-23 23:13:55]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Fady Samuel, 2016-02-23 23:51:00]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-23 23:53:32]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/320001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/320001

[piman, 2016-02-24 00:58:38]

lgtm

https://codereview.chromium.org/1711533002/diff/320001/content/common/gpu/ima...
File content/common/gpu/image_transport_surface_overlay_mac.mm (right):

https://codereview.chromium.org/1711533002/diff/320001/content/common/gpu/ima...
content/common/gpu/image_transport_surface_overlay_mac.mm:29: #include
"content/common/gpu/gpu_messages.h"
nit: Is this still needed?

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_child_...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:479: if (gpu_channel_manager_)
nit: I'd replace this test, and the other ones below, by a DCHECK.
gpu_channel_manager_ is setup in OnInitialize, which is the very first IPC
(before any of these happen), and there's no trust issue since the other end is
the browser process.

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_main.cc
File content/gpu/gpu_main.cc (right):

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_main.c...
content/gpu/gpu_main.cc:26: #include "content/common/gpu/gpu_messages.h"
nit: do you still need this?

[commit-bot: I haz the power, 2016-02-24 01:18:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 01:18:37]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2016-02-24 01:41:25]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[Fady Samuel, 2016-02-24 01:42:29]

fsamuel@chromium.org changed reviewers:
+ tsepez@chromium.org

[Fady Samuel, 2016-02-24 01:42:30]

+tsepez@ for IPC. Thanks!

https://codereview.chromium.org/1711533002/diff/320001/content/common/gpu/ima...
File content/common/gpu/image_transport_surface_overlay_mac.mm (right):

https://codereview.chromium.org/1711533002/diff/320001/content/common/gpu/ima...
content/common/gpu/image_transport_surface_overlay_mac.mm:29: #include
"content/common/gpu/gpu_messages.h"
On 2016/02/24 00:58:37, piman wrote:
> nit: Is this still needed?

Done.

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_child_...
File content/gpu/gpu_child_thread.cc (right):

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_child_...
content/gpu/gpu_child_thread.cc:479: if (gpu_channel_manager_)
On 2016/02/24 00:58:37, piman wrote:
> nit: I'd replace this test, and the other ones below, by a DCHECK.
> gpu_channel_manager_ is setup in OnInitialize, which is the very first IPC
> (before any of these happen), and there's no trust issue since the other end
is
> the browser process.

Done.

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_main.cc
File content/gpu/gpu_main.cc (right):

https://codereview.chromium.org/1711533002/diff/320001/content/gpu/gpu_main.c...
content/gpu/gpu_main.cc:26: #include "content/common/gpu/gpu_messages.h"
On 2016/02/24 00:58:37, piman wrote:
> nit: do you still need this?

Done.

[commit-bot: I haz the power, 2016-02-24 01:45:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/340001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/340001

[commit-bot: I haz the power, 2016-02-24 03:38:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 03:38:15]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2016-02-24 17:07:55]

The CQ bit was checked by fsamuel@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-24 17:10:40]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/360001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/360001

[Tom Sepez, 2016-02-24 17:46:43]

IPC lgtm.

[commit-bot: I haz the power, 2016-02-24 18:42:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 18:42:51]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2016-02-24 18:43:39]

The CQ bit was checked by fsamuel@chromium.org

[Fady Samuel, 2016-02-24 18:43:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
sievers@chromium.org, piman@chromium.org
Link to the patchset: https://codereview.chromium.org/1711533002/#ps360001
(title: "Rebased")

[commit-bot: I haz the power, 2016-02-24 18:52:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/360001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/360001

[commit-bot: I haz the power, 2016-02-24 19:15:48]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

[commit-bot: I haz the power, 2016-02-24 19:15:51]

Committed patchset #19 (id:360001)

[commit-bot: I haz the power, 2016-02-24 19:17:01]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}
==========

[commit-bot: I haz the power, 2016-02-24 19:17:04]

Patchset 19 (id:??) landed as
https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}

[shrike, 2016-02-25 00:01:03]

A revert of this CL (patchset #19 id:360001) has been created in
https://codereview.chromium.org/1730023004/ by shrike@chromium.org.

The reason for reverting is: Regression: Win7 Tests (dbg)(1) browser_test
failures

https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%2...

Sheriff-o-matic suspecting Change #198012 in Build 46233 for cause of Win7 Tests
(dbg)(1) browser_test failures:

https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%2...
In step 91. browser_tests 
failures:
    DevToolsPixelOutputTests.TestLatencyInfoInstrumentation
    DevToolsPixelOutputTests.TestScreenshotRecording
 
Logs:

https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%2...
https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%2...


[ RUN      ] DevToolsPixelOutputTests.TestLatencyInfoInstrumentation
[2840:5856:0224/124138:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Could not create D3D11 device.
[2840:5856:0224/124138:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D11 failed
with error EGL_NOT_INITIALIZED, trying next display type
[2840:5856:0224/124139:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Renderer does not support PS 3.0.aborting!
[2840:5856:0224/124139:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D9 failed
with error EGL_NOT_INITIALIZED
[2840:5856:0224/124139:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Could not create D3D11 device.
[2840:5856:0224/124139:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D11 failed
with error EGL_NOT_INITIALIZED, trying next display type
HTTP server started on http://127.0.0.1:58543...
sending server_data: {"host": "127.0.0.1", "port": 58543} (36 bytes)
[2840:5856:0224/124140:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Renderer does not support PS 3.0.aborting!
[2840:5856:0224/124140:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D9 failed
with error EGL_NOT_INITIALIZED
[2840:5856:0224/124140:ERROR:gl_surface_win.cc(69)]
GLSurfaceEGL::InitializeOneOff failed.
[2840:5856:0224/124140:ERROR:gpu_child_thread.cc(347)] Exiting GPU process due
to errors during initialization
[2840:5856:0224/124140:FATAL:gpu_child_thread.cc(484)] Check failed:
gpu_channel_manager_.
Backtrace:
	base::SysInfo::AmountOfVirtualMemory [0x100A8DB1+570092]
	base::SysInfo::AmountOfVirtualMemory [0x10100BCB+930054]
	content::ImageTransportFactory::ImageTransportFactory [0x176BA2F8+29889885]
	content::ImageTransportFactory::ImageTransportFactory [0x176B25D9+29857854]
	content::ImageTransportFactory::ImageTransportFactory [0x176B2118+29856637]
	content::ImageTransportFactory::ImageTransportFactory [0x176B23C6+29857323]
	content::ImageTransportFactory::ImageTransportFactory [0x176B141C+29853313]
	content::ImageTransportFactory::ImageTransportFactory [0x176BB492+29894391]
	IPC::Message::type [0x0FA2EA2B+166218]
	IPC::Message::type [0x0FA26F90+134831]
	IPC::Message::type [0x0FA26CE7+134150]
	IPC::Message::type [0x0FA2F6C2+169441]
	base::SysInfo::AmountOfVirtualMemory [0x1007C9BF+388858]
	base::SysInfo::AmountOfVirtualMemory [0x100AF147+595586]
	base::SysInfo::AmountOfVirtualMemory [0x1012E576+1116849]
	base::SysInfo::AmountOfVirtualMemory [0x1012BC74+1106351]
	base::SysInfo::AmountOfVirtualMemory [0x1012C43D+1108344]
	base::SysInfo::AmountOfVirtualMemory [0x10137E44+1155967]
	base::SysInfo::AmountOfVirtualMemory [0x10139E62+1164189]
	base::SysInfo::AmountOfVirtualMemory [0x10139DBC+1164023]
	base::SysInfo::AmountOfVirtualMemory [0x1012E1FF+1115962]
	base::SysInfo::AmountOfVirtualMemory [0x101C11C6+1718017]
	base::SysInfo::AmountOfVirtualMemory [0x1012E02D+1115496]
	content::ImageTransportFactory::ImageTransportFactory [0x176C0E20+29917317]
	content::ImageTransportFactory::ImageTransportFactory [0x15BEB179+1778654]
	content::ImageTransportFactory::ImageTransportFactory [0x15BEAF90+1778165]
	content::ImageTransportFactory::ImageTransportFactory [0x15BD4B70+1686997]
	content::LaunchTests [0x0849E65E+734]
	LaunchChromeTests [0x037F990D+125]
	main [0x01D5643E+110]
	__tmainCRTStartup [0x09B5DBE9+409]
(f:\ddctools\crt\crtw32\dllstuff\crtexe.c:626)
	mainCRTStartup [0x09B5DD2D+13] (f:\ddctools\crt\crtw32\dllstuff\crtexe.c:466)
	BaseThreadInitThunk [0x767C337A+18]
	RtlInitializeExceptionChain [0x77D29882+99]
	RtlInitializeExceptionChain [0x77D29855+54]

=================

[ RUN      ] DevToolsPixelOutputTests.TestScreenshotRecording
[2512:3528:0224/124026:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Could not create D3D11 device.
[2512:3528:0224/124026:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D11 failed
with error EGL_NOT_INITIALIZED, trying next display type
[2512:3528:0224/124026:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Renderer does not support PS 3.0.aborting!
[2512:3528:0224/124026:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D9 failed
with error EGL_NOT_INITIALIZED
[2512:3528:0224/124026:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Could not create D3D11 device.
[2512:3528:0224/124026:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D11 failed
with error EGL_NOT_INITIALIZED, trying next display type
[2512:3528:0224/124026:ERROR:angle_platform_impl.cc(33)] ANGLE
Display::initialize error 4: Renderer does not support PS 3.0.aborting!
[2512:3528:0224/124026:ERROR:gl_surface_egl.cc(586)] eglInitialize D3D9 failed
with error EGL_NOT_INITIALIZED
[2512:3528:0224/124026:ERROR:gl_surface_win.cc(69)]
GLSurfaceEGL::InitializeOneOff failed.
[2512:3528:0224/124026:ERROR:gpu_child_thread.cc(347)] Exiting GPU process due
to errors during initialization
HTTP server started on http://127.0.0.1:51161...
sending server_data: {"host": "127.0.0.1", "port": 51161} (36 bytes)
[4708:1384:0224/124028:WARNING:message_queue.cc(38)] Leaking 2 ports in
unreceived messages
[2512:3528:0224/124026:FATAL:gpu_child_thread.cc(484)] Check failed:
gpu_channel_manager_.
Backtrace:
	base::SysInfo::AmountOfVirtualMemory [0x100A8DB1+570092]
	base::SysInfo::AmountOfVirtualMemory [0x10100BCB+930054]
	content::ImageTransportFactory::ImageTransportFactory [0x1778A2F8+29889885]
	content::ImageTransportFactory::ImageTransportFactory [0x177825D9+29857854]
	content::ImageTransportFactory::ImageTransportFactory [0x17782118+29856637]
	content::ImageTransportFactory::ImageTransportFactory [0x177823C6+29857323]
	content::ImageTransportFactory::ImageTransportFactory [0x1778141C+29853313]
	content::ImageTransportFactory::ImageTransportFactory [0x1778B492+29894391]
	IPC::Message::type [0x0FAFEA2B+166218]
	IPC::Message::type [0x0FAF6F90+134831]
	IPC::Message::type [0x0FAF6CE7+134150]
	IPC::Message::type [0x0FAFF6C2+169441]
	base::SysInfo::AmountOfVirtualMemory [0x1007C9BF+388858]
	base::SysInfo::AmountOfVirtualMemory [0x100AF147+595586]
	base::SysInfo::AmountOfVirtualMemory [0x1012E576+1116849]
	base::SysInfo::AmountOfVirtualMemory [0x1012BC74+1106351]
	base::SysInfo::AmountOfVirtualMemory [0x1012C43D+1108344]
	base::SysInfo::AmountOfVirtualMemory [0x10137E44+1155967]
	base::SysInfo::AmountOfVirtualMemory [0x10139E62+1164189]
	base::SysInfo::AmountOfVirtualMemory [0x10139DBC+1164023]
	base::SysInfo::AmountOfVirtualMemory [0x1012E1FF+1115962]
	base::SysInfo::AmountOfVirtualMemory [0x101C11C6+1718017]
	base::SysInfo::AmountOfVirtualMemory [0x1012E02D+1115496]
	content::ImageTransportFactory::ImageTransportFactory [0x17790E20+29917317]
	content::ImageTransportFactory::ImageTransportFactory [0x15CBB179+1778654]
	content::ImageTransportFactory::ImageTransportFactory [0x15CBAF90+1778165]
	content::ImageTransportFactory::ImageTransportFactory [0x15CA4B70+1686997]
	content::LaunchTests [0x0849E65E+734]
	LaunchChromeTests [0x037F990D+125]
	main [0x01D5643E+110]
	__tmainCRTStartup [0x09B5DBE9+409]
(f:\ddctools\crt\crtw32\dllstuff\crtexe.c:626)
	mainCRTStartup [0x09B5DD2D+13] (f:\ddctools\crt\crtw32\dllstuff\crtexe.c:466)
	BaseThreadInitThunk [0x76C2337A+18]
	RtlInitializeExceptionChain [0x778692B2+99]
	RtlInitializeExceptionChain [0x77869285+54]

[3768:3420:0224/124033:ERROR:singleton_hwnd.cc(34)] Cannot create windows on
non-UI thread!
[4708:1384:0224/124034:ERROR:CONSOLE(72)] "Uncaught TypeError: Cannot read
property 'addExtensions' of undefined", source:  (72)
[4708:1384:0224/124035:INFO:CONSOLE(1)] "DONE:performActionsInPage.1", source: 
(1)
c:uild\slave\win_builder__dbg_uild\src\chromerowser\devtools\devtools_sanity_browsertest.cc(124):
error: Value of: result
  Actual: "[FAILED] Expected: 'true', but was 'false'"
Expected: "[OK]"
[4708:1384:0224/124038:WARNING:url_request_context_getter.cc(42)]
URLRequestContextGetter leaking due to no owning thread.
[  FAILED  ] DevToolsPixelOutputTests.TestScreenshotRecording, where TypeParam =
 and GetParam() =  (12746 ms)

.

[Fady Samuel, 2016-02-25 02:17:29]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}
==========

[Fady Samuel, 2016-02-25 02:29:02]

The CQ bit was checked by fsamuel@chromium.org

[Fady Samuel, 2016-02-25 02:29:03]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org,
sievers@chromium.org, piman@chromium.org
Link to the patchset: https://codereview.chromium.org/1711533002/#ps380001
(title: "Restored if guards on GpuChannelManager")

[commit-bot: I haz the power, 2016-02-25 02:33:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1711533002/380001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1711533002/380001

[commit-bot: I haz the power, 2016-02-25 03:56:24]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}
==========

[commit-bot: I haz the power, 2016-02-25 03:56:25]

Committed patchset #20 (id:380001)

[commit-bot: I haz the power, 2016-02-25 03:57:33]

Description was changed from

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}
==========

to

==========
Decouple browser-specific GPU IPC messages from GPU service IPCs

We would like Mus to reuse GPU service IPC messages. However,
browser-specific<=>gpu messages don't necessarily
make sense in Mus+Ash. This CL decouples browser messages
from Gpu channel messages in the following ways:

1. Browser channel messages are moved to a gpu_host_messages.h file.

2. Browser channel message handling is moved entirely to GpuChildThread.

3. GpuChannelManager is decoupled from GpuChildThread by making
GpuChildThread a GpuChannelManagerDelegate.

The intent here is for Mus to implement an alternative
GpuChannelManagerDelegate.

BUG=586374

Committed: https://crrev.com/6904b50eb105956b954279f9632f680251e41aa7
Cr-Commit-Position: refs/heads/master@{#377341}

Committed: https://crrev.com/a660ce06aa37e51a849f68d01d27ce3f36cbe626
Cr-Commit-Position: refs/heads/master@{#377496}
==========

[commit-bot: I haz the power, 2016-02-25 03:57:34]

Patchset 20 (id:??) landed as
https://crrev.com/a660ce06aa37e51a849f68d01d27ce3f36cbe626
Cr-Commit-Position: refs/heads/master@{#377496}