content: Handle OutputSurface requests correctly.

content: Handle OutputSurface requests correctly.

If the compositor goes through a visible, invisible and visible sequence,
we would end up queuing 2 GpuChannelHost requests. In this case, the
OutputSurface request is handled when the first callback runs. So
instead of asserting that there is a pending OutputSurface request when
the response callback for the GpuChannel request runs, early out if the
OutputSurface request was already handled.

BUG=643852
Committed: https://crrev.com/2010e7dd770842c852284502b4503c7843d05ff3
Cr-Commit-Position: refs/heads/master@{#416589}

[Khushal, 2016-09-06 04:24:04]

khushalsagar@chromium.org changed reviewers:
+ aelias@chromium.org

[aelias_OOO_until_Jul13, 2016-09-06 05:08:42]

lgtm to deflake the tests, but one thought for possible future cleanup attempt:

Would it be correct to delete the HandlePendingOutputSurfaceRequest call in
SetVisible() instead?    I wonder if it's still needed.  The codepath is complex
so I haven't proven this completely, but it looks like the scheduler kicks off a
next action when it becomes visible, then
SchedulerStateMachine::ShouldBeginOutputSurfaceCreation() should return true
after that.

[Khushal, 2016-09-06 05:12:27]

The CQ bit was checked by khushalsagar@chromium.org

[commit-bot: I haz the power, 2016-09-06 05:12:41]

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

[Khushal, 2016-09-06 05:19:29]

On 2016/09/06 05:08:42, aelias wrote:
> lgtm to deflake the tests, but one thought for possible future cleanup
attempt:
> 
> Would it be correct to delete the HandlePendingOutputSurfaceRequest call in
> SetVisible() instead?    I wonder if it's still needed.  The codepath is
complex
> so I haven't proven this completely, but it looks like the scheduler kicks off
a
> next action when it becomes visible, then
> SchedulerStateMachine::ShouldBeginOutputSurfaceCreation() should return true
> after that.

Thanks Alex. I think the Scheduler would do this only if an OutputSurface has
not been requested from the client already. So the first time we become visible,
the scheduler would kick off the OutputSurface creation and set the state to
OUTPUT_SURFACE_CREATING. If we go through a sequence of visibility changes after
this, OutputSurfaceState would remain unchanged till we provide the
LayerTreeHost with an OutputSurface, and the Scheduler would not request for an
OutputSurface again.

[commit-bot: I haz the power, 2016-09-06 05:45:58]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-06 05:48:02]

Description was changed from

==========
content: Handle OutputSurface requests correctly.

If the compositor goes through a visible, invisible and visible sequence,
we would end up queuing 2 GpuChannelHost requests. In this case, the
OutputSurface request is handled when the first callback runs. So
instead of asserting that there is a pending OutputSurface request when
the response callback for the GpuChannel request runs, early out if the
OutputSurface request was already handled.

BUG=643852
==========

to

==========
content: Handle OutputSurface requests correctly.

If the compositor goes through a visible, invisible and visible sequence,
we would end up queuing 2 GpuChannelHost requests. In this case, the
OutputSurface request is handled when the first callback runs. So
instead of asserting that there is a pending OutputSurface request when
the response callback for the GpuChannel request runs, early out if the
OutputSurface request was already handled.

BUG=643852

Committed: https://crrev.com/2010e7dd770842c852284502b4503c7843d05ff3
Cr-Commit-Position: refs/heads/master@{#416589}
==========

[commit-bot: I haz the power, 2016-09-06 05:48:03]

Patchset 1 (id:??) landed as
https://crrev.com/2010e7dd770842c852284502b4503c7843d05ff3
Cr-Commit-Position: refs/heads/master@{#416589}