Introduce Display Compositor mojo interface. Use InProcessContextProvider.

Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in a single
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead
requesting a CompositorFrameSink from Mus-GPU (still in the same process for now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code is
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create
InProcessContextProviders instead of SurfacesContextProviders (which use a
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used
internally by the display compositor.

BUG=610937, 661278
Committed: https://crrev.com/4af1869e97cdf585994c422c22423f6d6fcf68ce
Cr-Commit-Position: refs/heads/master@{#433990}

[Fady Samuel, 2016-11-07 16:32:31]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

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

to

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-15 18:31:02]

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

[commit-bot: I haz the power, 2016-11-15 18:32:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-15 18:37:57]

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

[commit-bot: I haz the power, 2016-11-15 18:37:58]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Fady Samuel, 2016-11-19 18:10:56]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface


This CL makes a number of changes. I think it's easier to put it all together in
a single CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create
CompositorFrameSinks and to update surface references (SurfaceSequences for
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead requesting
a CompositorFrameSink from Mus-GPU (still in the same process for now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create
InProcessContextProviders instead of SurfacesContextProviders (which use a
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 18:11:17]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface


This CL makes a number of changes. I think it's easier to put it all together in
a single CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create
CompositorFrameSinks and to update surface references (SurfaceSequences for
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead requesting
a CompositorFrameSink from Mus-GPU (still in the same process for now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create
InProcessContextProviders instead of SurfacesContextProviders (which use a
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 18:11:31]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 18:12:26]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

6. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 18:13:46]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. SurfacesContextProvider has been deleted.

6. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.
. 
BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 19:45:22]

Description was changed from

==========
WIP: Move ComposiorFrameSink to gpu. Add CreateCompositorFrameSink mojo
interface

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.
. 
BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.
. 
BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 19:46:55]

Description was changed from

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.
. 
BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Fady Samuel, 2016-11-19 19:47:42]

fsamuel@chromium.org changed reviewers:
+ rjkroege@chromium.org, sadrul@chromium.org

[Fady Samuel, 2016-11-19 19:47:43]

+rjkroege@, +sadrul@ PTAL

Just like that Mus-WS no longer accesses the display compositor directly :-)

[Fady Samuel, 2016-11-19 19:47:51]

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

[commit-bot: I haz the power, 2016-11-19 19:48:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-19 19:48:58]

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

[commit-bot: I haz the power, 2016-11-19 19:48:59]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-21 00:30:20]

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

[commit-bot: I haz the power, 2016-11-21 00:30:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-21 00:31:23]

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

[commit-bot: I haz the power, 2016-11-21 00:31:24]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-21 05:14:50]

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

[commit-bot: I haz the power, 2016-11-21 05:15:03]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-21 05:16:17]

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

[commit-bot: I haz the power, 2016-11-21 05:16:19]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-21 13:33:21]

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

[commit-bot: I haz the power, 2016-11-21 13:33:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-21 13:35:13]

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

[commit-bot: I haz the power, 2016-11-21 13:35:14]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-21 16:07:56]

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

[commit-bot: I haz the power, 2016-11-21 16:08:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-21 16:10:17]

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

[commit-bot: I haz the power, 2016-11-21 16:10:18]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[sadrul, 2016-11-21 17:23:50]

https://codereview.chromium.org/2481263002/diff/490001/gpu/ipc/gpu_in_process...
File gpu/ipc/gpu_in_process_thread_service.h (right):

https://codereview.chromium.org/2481263002/diff/490001/gpu/ipc/gpu_in_process...
gpu/ipc/gpu_in_process_thread_service.h:16: // Default Service class when a null
service is used.
What is a 'null service'?

https://codereview.chromium.org/2481263002/diff/490001/services/ui/common/DEPS
File services/ui/common/DEPS (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/common/DEP...
services/ui/common/DEPS:6: "+services/ui/gpu/interfaces"
Is this still needed?

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
File services/ui/gpu/gpu_service_internal.cc (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:51:
compositor_thread_("GpuCompositorThread") {
DisplayCompositorThread?

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:97: DCHECK(!gpu_command_service_);
DCHECK(CalledOnValidThread())

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:104:
compositor_thread_.task_runner()->PostTask(
Why does DC need to live in a separate thread? (I am not saying it shouldn't or
doesn't need to, but I want to learn why :) )

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:116: mojom::GpuServiceInternalPtr
gpu_service_ptr;
DCHECK(compositor_thread_.task_runner()->BelongsToCurrentThread())

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
File services/ui/gpu/gpu_service_internal.h (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.h:132:
mojo::BindingSet<mojom::GpuServiceInternal> bindings_;
The window server should normally be the only client. What else is connecting to
this?

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/frame_g...
File services/ui/ws/frame_generator.cc (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/frame_g...
services/ui/ws/frame_generator.cc:46: DCHECK(widget !=
gfx::kNullAcceleratedWidget);
DCHECK_NE

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.cc (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.cc:61: // TODO(fsamuel): What is this thread
used for?
See comment in .h

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.h (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.h:77: scoped_refptr<gpu::GpuChannelHost>
gpu_channel_;
Remove this? Since you are not creating it anymore, GpuServiceProxy does not
need to be a GpuChannelHostFactory either. That also means you can get rid of
|io_thread_|, |shutdown_event_|

[Fady Samuel, 2016-11-21 20:40:26]

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

[Fady Samuel, 2016-11-21 20:40:41]

PTAL Sadrul, Rob!

https://codereview.chromium.org/2481263002/diff/490001/gpu/ipc/gpu_in_process...
File gpu/ipc/gpu_in_process_thread_service.h (right):

https://codereview.chromium.org/2481263002/diff/490001/gpu/ipc/gpu_in_process...
gpu/ipc/gpu_in_process_thread_service.h:16: // Default Service class when a null
service is used.
On 2016/11/21 17:23:49, sadrul wrote:
> What is a 'null service'?

Improved comment.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/common/DEPS
File services/ui/common/DEPS (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/common/DEP...
services/ui/common/DEPS:6: "+services/ui/gpu/interfaces"
On 2016/11/21 17:23:49, sadrul wrote:
> Is this still needed?

No, gone.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
File services/ui/gpu/gpu_service_internal.cc (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:51:
compositor_thread_("GpuCompositorThread") {
On 2016/11/21 17:23:49, sadrul wrote:
> DisplayCompositorThread?

Done.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:97: DCHECK(!gpu_command_service_);
On 2016/11/21 17:23:49, sadrul wrote:
> DCHECK(CalledOnValidThread())

Done.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:104:
compositor_thread_.task_runner()->PostTask(
On 2016/11/21 17:23:49, sadrul wrote:
> Why does DC need to live in a separate thread? (I am not saying it shouldn't
or
> doesn't need to, but I want to learn why :) )

InProcessCommandBuffer can block on progress on the gpu thread. E.g.:
https://cs.chromium.org/chromium/src/gpu/ipc/in_process_command_buffer.cc?sq=...

We don't want this to all be one thread or else we'll deadlock.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.cc:116: mojom::GpuServiceInternalPtr
gpu_service_ptr;
On 2016/11/21 17:23:49, sadrul wrote:
> DCHECK(compositor_thread_.task_runner()->BelongsToCurrentThread())

Done.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
File services/ui/gpu/gpu_service_internal.h (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.h:132:
mojo::BindingSet<mojom::GpuServiceInternal> bindings_;
On 2016/11/21 17:23:49, sadrul wrote:
> The window server should normally be the only client. What else is connecting
to
> this?

MusGpuMemoryBufferManager lives on the compositor thread but connects to
GpuServiceInternal on the gpu thread. We're letting mojo deal with the thread
hop here.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/frame_g...
File services/ui/ws/frame_generator.cc (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/frame_g...
services/ui/ws/frame_generator.cc:46: DCHECK(widget !=
gfx::kNullAcceleratedWidget);
On 2016/11/21 17:23:49, sadrul wrote:
> DCHECK_NE

Done.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.cc (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.cc:61: // TODO(fsamuel): What is this thread
used for?
On 2016/11/21 17:23:49, sadrul wrote:
> See comment in .h

Deleted.

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.h (right):

https://codereview.chromium.org/2481263002/diff/490001/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.h:77: scoped_refptr<gpu::GpuChannelHost>
gpu_channel_;
On 2016/11/21 17:23:49, sadrul wrote:
> Remove this? Since you are not creating it anymore, GpuServiceProxy does not
> need to be a GpuChannelHostFactory either. That also means you can get rid of
> |io_thread_|, |shutdown_event_|

Done.

[commit-bot: I haz the power, 2016-11-21 20:41:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-21 20:44:43]

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

[commit-bot: I haz the power, 2016-11-21 20:44:44]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[rjkroege, 2016-11-21 23:05:36]

https://codereview.chromium.org/2481263002/diff/430002/cc/ipc/display_composi...
File cc/ipc/display_compositor.mojom (right):

https://codereview.chromium.org/2481263002/diff/430002/cc/ipc/display_composi...
cc/ipc/display_compositor.mojom:17: interface DisplayCompositor {
Please note how normal clients make themselves CompositorFrameSinks here.
Perhaps a ref to the appropriate .mojom file.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/gpu/gpu_se...
File services/ui/gpu/gpu_service_internal.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.h:107: void
CreateDisplayCompositorOnCompositorThread(
how are the threads going to be identified in the musgpu?
In particular, ozone will need to do PostTask's to specific threads (gpu,
compositor) so having the compositor_thread_ embedded here as a private will be
inconvenient. 

I'd like more text about how the threads are built and connected.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/surfaces/d...
File services/ui/surfaces/direct_output_surface_ozone.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/surfaces/d...
services/ui/surfaces/direct_output_surface_ozone.h:76: // Called when a swap
completion is sent from the GPU process.
the comment is wrong. please fix it.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.cc (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.cc:24: // The client Id 1 is reserved for the
display compositor.
the guessable number has security implications?

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.h:38: void
CreateDisplayCompositor(cc::mojom::DisplayCompositorRequest request,
method docs?

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/server_...
File services/ui/ws/server_window_delegate.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/server_...
services/ui/ws/server_window_delegate.h:30: virtual
cc::mojom::DisplayCompositor* GetDisplayCompositor() = 0;
doc method?

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
File services/ui/ws/window_finder.cc (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
services/ui/ws/window_finder.cc:8: #include
"services/ui/surfaces/gpu_compositor_frame_sink.h"
doesn't seem like anything else changed. do you need this include?

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
services/ui/ws/window_server.cc:497: void WindowServer::OnDisplayReady(Display*
display, bool is_first) {
Please explain the thread startup ordering. Particularly in a CrOS context.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
services/ui/ws/window_server.cc:745: void
WindowServer::OnGpuServiceInitialized() {
the declaration of this method requires more documentation.

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

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

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

PTAL Rob, Sadrul!

https://codereview.chromium.org/2481263002/diff/430002/cc/ipc/display_composi...
File cc/ipc/display_compositor.mojom (right):

https://codereview.chromium.org/2481263002/diff/430002/cc/ipc/display_composi...
cc/ipc/display_compositor.mojom:17: interface DisplayCompositor {
On 2016/11/21 23:05:36, rjkroege wrote:
> Please note how normal clients make themselves CompositorFrameSinks here.
> Perhaps a ref to the appropriate .mojom file.

Done.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/gpu/gpu_se...
File services/ui/gpu/gpu_service_internal.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/gpu/gpu_se...
services/ui/gpu/gpu_service_internal.h:107: void
CreateDisplayCompositorOnCompositorThread(
On 2016/11/21 23:05:36, rjkroege wrote:
> how are the threads going to be identified in the musgpu?
> In particular, ozone will need to do PostTask's to specific threads (gpu,
> compositor) so having the compositor_thread_ embedded here as a private will
be
> inconvenient. 
> 
> I'd like more text about how the threads are built and connected.

Done.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/surfaces/d...
File services/ui/surfaces/direct_output_surface_ozone.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/surfaces/d...
services/ui/surfaces/direct_output_surface_ozone.h:76: // Called when a swap
completion is sent from the GPU process.
On 2016/11/21 23:05:36, rjkroege wrote:
> the comment is wrong. please fix it.

Done.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.cc (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.cc:24: // The client Id 1 is reserved for the
display compositor.
On 2016/11/21 23:05:36, rjkroege wrote:
> the guessable number has security implications?

I don't think so because the display compositor will never respond to IPC. It
uses in an InProcessCommandBuffer.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
File services/ui/ws/gpu_service_proxy.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/gpu_ser...
services/ui/ws/gpu_service_proxy.h:38: void
CreateDisplayCompositor(cc::mojom::DisplayCompositorRequest request,
On 2016/11/21 23:05:36, rjkroege wrote:
> method docs?

Done.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/server_...
File services/ui/ws/server_window_delegate.h (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/server_...
services/ui/ws/server_window_delegate.h:30: virtual
cc::mojom::DisplayCompositor* GetDisplayCompositor() = 0;
On 2016/11/21 23:05:36, rjkroege wrote:
> doc method?

Done.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
File services/ui/ws/window_finder.cc (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
services/ui/ws/window_finder.cc:8: #include
"services/ui/surfaces/gpu_compositor_frame_sink.h"
On 2016/11/21 23:05:36, rjkroege wrote:
> doesn't seem like anything else changed. do you need this include?

No, I'm not sure how it got in here. Rebase error?

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
services/ui/ws/window_server.cc:497: void WindowServer::OnDisplayReady(Display*
display, bool is_first) {
On 2016/11/21 23:05:36, rjkroege wrote:
> Please explain the thread startup ordering. Particularly in a CrOS context. 

Done.

https://codereview.chromium.org/2481263002/diff/430002/services/ui/ws/window_...
services/ui/ws/window_server.cc:745: void
WindowServer::OnGpuServiceInitialized() {
On 2016/11/21 23:05:36, rjkroege wrote:
> the declaration of this method requires more documentation. 

Done.

[commit-bot: I haz the power, 2016-11-22 01:02:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-22 01:05:39]

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

[commit-bot: I haz the power, 2016-11-22 01:05:40]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-22 03:08:54]

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

[commit-bot: I haz the power, 2016-11-22 03:09:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-22 03:11:00]

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

[commit-bot: I haz the power, 2016-11-22 03:11:01]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-22 04:15:57]

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

[commit-bot: I haz the power, 2016-11-22 04:16:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-22 04:17:38]

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

[commit-bot: I haz the power, 2016-11-22 04:17:40]

Dry run: Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[rjkroege, 2016-11-22 18:26:26]

lgtm

lgtm

https://codereview.chromium.org/2481263002/diff/580001/services/ui/surfaces/d...
File services/ui/surfaces/direct_output_surface.cc (right):

https://codereview.chromium.org/2481263002/diff/580001/services/ui/surfaces/d...
services/ui/surfaces/direct_output_surface.cc:79: // Can it have alpha?
cc::InProcessContextProvider doesn't take any
Purely informational comment: As danakj points out, this function does not
return the correct value on all platforms and for platforms other than
CrOS/Ozone, it would require adjustment.

[rjkroege, 2016-11-22 18:26:32]

lgtm

[Fady Samuel, 2016-11-22 18:30:28]

fsamuel@chromium.org changed reviewers:
+ piman@chromium.org, sky@chromium.org, tsepez@chromium.org

[Fady Samuel, 2016-11-22 18:30:29]

+sky@ for services/ui
+piman@ for cc and gpu
+tsepez@ for mojom.

[Tom Sepez, 2016-11-22 18:39:15]

https://codereview.chromium.org/2481263002/diff/580001/services/ui/gpu/interf...
File services/ui/gpu/interfaces/gpu_service_internal.mojom (right):

https://codereview.chromium.org/2481263002/diff/580001/services/ui/gpu/interf...
services/ui/gpu/interfaces/gpu_service_internal.mojom:38:
CreateDisplayCompositor(
Who has access to this interface?

[Fady Samuel, 2016-11-22 18:41:23]

PTAL tsepez@

https://codereview.chromium.org/2481263002/diff/580001/services/ui/gpu/interf...
File services/ui/gpu/interfaces/gpu_service_internal.mojom (right):

https://codereview.chromium.org/2481263002/diff/580001/services/ui/gpu/interf...
services/ui/gpu/interfaces/gpu_service_internal.mojom:38:
CreateDisplayCompositor(
On 2016/11/22 18:39:15, Tom Sepez wrote:
> Who has access to this interface?  

The window server only. All of GpuServiceInternal is only used by the window
server.

[Tom Sepez, 2016-11-22 18:48:33]

lgtm

[Fady Samuel, 2016-11-22 21:05:07]

Description was changed from

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references (SurfaceSequences for 
now).

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[sky, 2016-11-22 21:05:14]

LGTM

[piman, 2016-11-22 21:07:50]

lgtm

[Fady Samuel, 2016-11-22 21:08:11]

The CQ bit was checked by fsamuel@chromium.org

[commit-bot: I haz the power, 2016-11-22 21:09:00]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-22 21:11:32]

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

[commit-bot: I haz the power, 2016-11-22 21:11:35]

Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-22 21:17:49]

The CQ bit was checked by fsamuel@chromium.org

[commit-bot: I haz the power, 2016-11-22 21:18:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-22 21:20:45]

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

[commit-bot: I haz the power, 2016-11-22 21:20:47]

Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED, no build URL)

[Fady Samuel, 2016-11-22 21:32:12]

Description was changed from

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
==========

[Fady Samuel, 2016-11-22 21:32:23]

The CQ bit was checked by fsamuel@chromium.org

[commit-bot: I haz the power, 2016-11-22 21:33:13]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-22 21:41:38]

CQ is committing da patch.

Bot data: {"patchset_id": 580001, "attempt_start_ts": 1479850343880770,
"parent_rev": "140c7fb6405222d765f5d42026d4d56dc852c174", "commit_rev":
"0a3789d53d7a4278816361fdb651f78f7c08af91"}

[commit-bot: I haz the power, 2016-11-22 21:42:01]

Description was changed from

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
==========

to

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
==========

[commit-bot: I haz the power, 2016-11-22 21:42:03]

Committed patchset #31 (id:580001)

[commit-bot: I haz the power, 2016-11-22 21:44:26]

Description was changed from

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single 
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create 
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead 
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is 
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create 
InProcessContextProviders instead of SurfacesContextProviders (which use a 
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used 
internally by the display compositor.

BUG=610937, 661278
==========

to

==========
Introduce Display Compositor mojo interface. Use InProcessContextProvider.

This CL makes a number of changes. I think it's easier to put it all together in
a single
CL and easier to review. Here are the notable changes:

1. A new DisplayCompositor mojo interface has been introduced to create
CompositorFrameSinks and to update surface references.

2. Mus-WS code no longer knows about GpuCompositorFrameSink, instead
requesting a CompositorFrameSink from Mus-GPU (still in the same process for
now).

3. Mus-WS no longer creates an internal GPU channel as display compositor code
is
no longer accessed directly by Mus-WS.

4. Root windows with valid AcceleratedWidgets now create
InProcessContextProviders instead of SurfacesContextProviders (which use a
GpuChannelHost).

5. DirectOutputSurface, and DirectOutputSurfaceOzone no longer use
SurfacesContextProvider.

6. SurfacesContextProvider has been deleted.

7. MusGpuCompositorFrameSink moves out of window server code as it's only used
internally by the display compositor.

BUG=610937, 661278

Committed: https://crrev.com/4af1869e97cdf585994c422c22423f6d6fcf68ce
Cr-Commit-Position: refs/heads/master@{#433990}
==========

[commit-bot: I haz the power, 2016-11-22 21:44:29]

Patchset 31 (id:??) landed as
https://crrev.com/4af1869e97cdf585994c422c22423f6d6fcf68ce
Cr-Commit-Position: refs/heads/master@{#433990}