Remove --no-use-mus-in-renderer

Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substantial refactoring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
TBR=piman@chromium.org

Review-Url: https://codereview.chromium.org/2762873002
Cr-Commit-Position: refs/heads/master@{#458470}
Committed: https://chromium.googlesource.com/chromium/src/+/098eade5b1d916d43bbd0c9efba86734b66f9198

[Fady Samuel, 2017-03-21 02:28:01]

Description was changed from

==========
Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substational refacotring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
==========

to

==========
Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substantial refactoring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
==========

[Fady Samuel, 2017-03-21 02:28:41]

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

[Fady Samuel, 2017-03-21 02:28:41]

+sadrul@ FYI, as we discussed
+piman@ please review all.

[Fady Samuel, 2017-03-21 02:29:04]

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

[commit-bot: I haz the power, 2017-03-21 02:29:25]

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, 2017-03-21 04:01:14]

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

[commit-bot: I haz the power, 2017-03-21 04:01:14]

Dry run: This issue passed the CQ dry run.

[sadrul, 2017-03-21 17:04:47]

cool! lgtm!

[Fady Samuel, 2017-03-21 17:52:59]

TBRing piman@ since this is mostly just deleting some mus code from content.

[Fady Samuel, 2017-03-21 17:55:38]

Description was changed from

==========
Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substantial refactoring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
==========

to

==========
Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substantial refactoring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
TBR=piman@chromium.org
==========

[Fady Samuel, 2017-03-21 17:55:46]

The CQ bit was checked by fsamuel@chromium.org

[commit-bot: I haz the power, 2017-03-21 17:56:27]

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, 2017-03-21 18:06:20]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1490118946879180, "parent_rev":
"3e94eda8b670fa91fff645beaa8cce479055e092", "commit_rev":
"098eade5b1d916d43bbd0c9efba86734b66f9198"}

[commit-bot: I haz the power, 2017-03-21 18:07:02]

Description was changed from

==========
Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substantial refactoring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
TBR=piman@chromium.org
==========

to

==========
Remove --no-use-mus-in-renderer

use-mus-in-renderer mostly works (save for WebView/OOPIF) and that is being
actively worked on. Removing this code path simplifies and unblocks further
work on surface synchronization.

In particular, currently, in Mus+Ash there is a mix of Chrome generated
FrameSinkIds and Mus generated FrameSinkIds which complicates debugging
and results in subtle bugs. In a new, upcoming, code path requesting
CompositorFrameSinks becomes async and the FrameSinkId used to create
a CompositorFrameSink is allocated from the window server.
MusBrowserCompositorOutputSurface expects to receive a CompositorFrameSink
synchronously and is deeply embedded into GpuProcessTransportFactory.
In order to support the new control flow substantial refactoring
is necessary in GpuProcessTransportFactory.

This seemed overkill for a deprecated, soon-to-disappear codepath.
This CL makes the code path disappear.

BUG=672962
TBR=piman@chromium.org

Review-Url: https://codereview.chromium.org/2762873002
Cr-Commit-Position: refs/heads/master@{#458470}
Committed:
https://chromium.googlesource.com/chromium/src/+/098eade5b1d916d43bbd0c9efba8...
==========

[commit-bot: I haz the power, 2017-03-21 18:07:03]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/098eade5b1d916d43bbd0c9efba8...

[stanisc, 2017-03-28 18:14:22]

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

[stanisc, 2017-03-28 18:14:23]

I've just noticed a couple of these small issues when investigating another bug.

https://codereview.chromium.org/2762873002/diff/1/content/browser/compositor/...
File content/browser/compositor/gpu_process_transport_factory.cc (left):

https://codereview.chromium.org/2762873002/diff/1/content/browser/compositor/...
content/browser/compositor/gpu_process_transport_factory.cc:563:
begin_frame_source = mus_output_surface->GetBeginFrameSource();
Now that this line of code is removed it doesn't make sense to declare
begin_frame_source further above.

https://codereview.chromium.org/2762873002/diff/1/content/browser/compositor/...
content/browser/compositor/gpu_process_transport_factory.cc:577: if
(!begin_frame_source) {
With the mus case removed above begin_frame_source will always be nullptr, so
this condition isn't needed anymore. I also recommend moving begin_frame_source
declaration here.