cc: Get rid of LayerTreeHost::output_surface_lost_ state.

cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

The only exception is SingleThreadProxy needs to know to request
and output surface when doing synchronous composite things. So it does
that itself now.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

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

[danakj, 2016-08-23 01:00:48]

Description was changed from

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

R=enne
BUG=606056
==========

to

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[danakj, 2016-08-23 01:03:43]

Description was changed from

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

The only exception is SingleThreadProxy needs to know to request
and output surface when doing synchronous composite things. So it does
that itself now.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[Justin Novosad, 2016-08-23 14:54:54]

On 2016/08/23 01:00:51, danakj wrote:

non-Owner lgtm

[enne (OOO), 2016-08-23 17:25:59]

enne@chromium.org changed reviewers:
+ junov@chromium.org

[enne (OOO), 2016-08-23 17:26:00]

lgtm

https://codereview.chromium.org/2270573002/diff/20001/cc/trees/proxy_main.cc
File cc/trees/proxy_main.cc (left):

https://codereview.chromium.org/2270573002/diff/20001/cc/trees/proxy_main.cc#...
cc/trees/proxy_main.cc:162: if (layer_tree_host_->output_surface_lost()) {
Ohmygosh so glad to get rid of this conditional.

[danakj, 2016-08-25 00:31:11]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-08-25 00:31:11]

The patchset sent to the CQ was uploaded after l-g-t-m from junov@chromium.org,
enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2270573002/#ps40001
(title: "lth-outputsurface-lost: rebase")

[commit-bot: I haz the power, 2016-08-25 00:33:26]

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-08-25 00:47:25]

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

[commit-bot: I haz the power, 2016-08-25 00:47:26]

Try jobs failed on following builders:
  linux_precise_blink_rel on master.tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_precise_blink_rel/...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[danakj, 2016-08-25 00:51:55]

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

[commit-bot: I haz the power, 2016-08-25 00:52:34]

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

[danakj, 2016-08-25 00:53:10]

Oh, so ui::Compositor was using the lost bit on LTH to skip calling
ReleaseOutputSurface.

This is the same as it checking if Compositor::DidInitializeOutputSurface
happened. But Compositor::DidFailToInitializeOutputSurface can't happen (DCHECK
verifies this) since the context is already bound. And single-thread says that
when you SetOutputSurface we will initialize it in the same stack.

So. This is the same as checking if we have called SetOutputSurface and not
received RequestNewOutputSurface (aka is there a surface in cc) or not. So I
added a bool to ui::Compositor for this.

[danakj, 2016-08-25 00:57:26]

The CQ bit was unchecked by danakj@chromium.org

[danakj, 2016-08-25 00:57:30]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-08-25 00:57:30]

The patchset sent to the CQ was uploaded after l-g-t-m from junov@chromium.org,
enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2270573002/#ps60001
(title: "lth-outputsurface-lost: ui")

[danakj, 2016-08-25 00:57:33]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2016-08-25 00:58:05]

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-08-25 01:12:00]

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

[commit-bot: I haz the power, 2016-08-25 01:12:01]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[danakj, 2016-08-25 01:14:45]

danakj@chromium.org changed reviewers:
+ nyquist@chromium.org

[danakj, 2016-08-25 01:14:46]

+nyquist for blimp

[danakj, 2016-08-25 01:15:00]

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

[commit-bot: I haz the power, 2016-08-25 01:15:45]

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-08-25 01:43:24]

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

[commit-bot: I haz the power, 2016-08-25 01:43:25]

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

[danakj, 2016-08-25 01:56:56]

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

[commit-bot: I haz the power, 2016-08-25 01:57:40]

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

[danakj, 2016-08-25 02:01:36]

danakj@chromium.org changed reviewers:
+ sadrul@chromium.org

[danakj, 2016-08-25 02:01:36]

+sadrul for ui/aura/ and ui/views/ OWNERS (aura_demo crashes anyways for some
other reason, but you know..)

enne: PTAL

I've dropped the output_surface_valid_ in ui::Compositor. Here's my
observations.

- We were deferring registering child->parent relationships when we didn't have
an output surface, then re-registering them when we got a new output surface.
- But we only re-registered if the parent id (the ui::Compositor's id) was new.
However due to stuff fsamuel did (I think), this id is a const. The id is
surface_id_allocator_->client_id(). The surface_id_allocator_ is created at
construction of ui::Compositor and never changed. and the client_id() returns a
const member of it.

So, just register child->parent relationship as soon as its known, un-tie this
from output surface state at all, and stop trying to re-register (we wouldn't
anyways) when we make a new output surface.

I also got rid of LTH::has_output_surface() which some of this code was using.
And I stopped us acting like SurfaceManager might not exist. It always does,
except in some demo apps which I fixed.

[danakj, 2016-08-25 02:01:41]

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

[commit-bot: I haz the power, 2016-08-25 02:02:44]

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

[danakj, 2016-08-25 02:04:00]

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

[commit-bot: I haz the power, 2016-08-25 02:04:45]

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-08-25 02:28:41]

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

[commit-bot: I haz the power, 2016-08-25 02:28:42]

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...)

[Fady Samuel, 2016-08-25 02:43:05]

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

[Fady Samuel, 2016-08-25 02:43:06]

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

[Fady Samuel, 2016-08-25 02:43:06]

https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
File ui/compositor/compositor.cc (right):

https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
ui/compositor/compositor.cc:253:
context_factory_->GetSurfaceManager()->RegisterSurfaceNamespaceHierarchy(
This all kind of goes in the opposite direction of where I was hoping to go.

I wanted to tie SurfaceFactory to a particular client and tie all this
registration stuff to SurfaceFactory lifetime (creation and destruction).

Thus you can't register hierarchies until you have a SurfaceFactory.

We hope to pull SurfaceManager and SurfaceFactory (all display compositor
things) into the gpu process for both tadpole and salamander and so I was hoping
to make this code more async friendly.

I've been prototyping this in jellyfish to convince myself it'll work and I'm
pretty close to being convinced :-)

This is change in ui::Compositor blocking your CL?

[Fady Samuel, 2016-08-25 02:43:06]

https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
File ui/compositor/compositor.cc (right):

https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
ui/compositor/compositor.cc:253:
context_factory_->GetSurfaceManager()->RegisterSurfaceNamespaceHierarchy(
This all kind of goes in the opposite direction of where I was hoping to go.

I wanted to tie SurfaceFactory to a particular client and tie all this
registration stuff to SurfaceFactory lifetime (creation and destruction).

Thus you can't register hierarchies until you have a SurfaceFactory.

We hope to pull SurfaceManager and SurfaceFactory (all display compositor
things) into the gpu process for both tadpole and salamander and so I was hoping
to make this code more async friendly.

I've been prototyping this in jellyfish to convince myself it'll work and I'm
pretty close to being convinced :-)

This is change in ui::Compositor blocking your CL?

[piman, 2016-08-25 03:33:44]

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

[piman, 2016-08-25 03:33:45]

https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
File ui/compositor/compositor.cc (right):

https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
ui/compositor/compositor.cc:253:
context_factory_->GetSurfaceManager()->RegisterSurfaceNamespaceHierarchy(
On 2016/08/25 02:43:06, Fady Samuel wrote:
> This all kind of goes in the opposite direction of where I was hoping to go.
> 
> I wanted to tie SurfaceFactory to a particular client and tie all this
> registration stuff to SurfaceFactory lifetime (creation and destruction).
> 
> Thus you can't register hierarchies until you have a SurfaceFactory.

Does the SurfaceFactory have to be tied to the OutputSurface? Couldn't it be
owned by GpuProcessTransportFactory (on a per-compositor basis) and
predate/outlive the OutputSurfaces?

> 
> We hope to pull SurfaceManager and SurfaceFactory (all display compositor
> things) into the gpu process for both tadpole and salamander and so I was
hoping
> to make this code more async friendly.
> 
> I've been prototyping this in jellyfish to convince myself it'll work and I'm
> pretty close to being convinced :-)
> 
> This is change in ui::Compositor blocking your CL?

[sadrul, 2016-08-25 03:40:58]

aura views lgtm

[Fady Samuel, 2016-08-25 14:05:54]

On 2016/08/25 03:33:45, piman OOO back 2016-08-29 wrote:
>
https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
> File ui/compositor/compositor.cc (right):
> 
>
https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
> ui/compositor/compositor.cc:253:
> context_factory_->GetSurfaceManager()->RegisterSurfaceNamespaceHierarchy(
> On 2016/08/25 02:43:06, Fady Samuel wrote:
> > This all kind of goes in the opposite direction of where I was hoping to go.
> > 
> > I wanted to tie SurfaceFactory to a particular client and tie all this
> > registration stuff to SurfaceFactory lifetime (creation and destruction).
> > 
> > Thus you can't register hierarchies until you have a SurfaceFactory.
> 
> Does the SurfaceFactory have to be tied to the OutputSurface? Couldn't it be
> owned by GpuProcessTransportFactory (on a per-compositor basis) and
> predate/outlive the OutputSurfaces?
> 
> > 
> > We hope to pull SurfaceManager and SurfaceFactory (all display compositor
> > things) into the gpu process for both tadpole and salamander and so I was
> hoping
> > to make this code more async friendly.
> > 
> > I've been prototyping this in jellyfish to convince myself it'll work and
I'm
> > pretty close to being convinced :-)
> > 
> > This is change in ui::Compositor blocking your CL?

Yes, you're right. SurfaceFactory can be pulled out of OutputSurface.

Some background: My current mental model (and you can kind of see this in
jellyfish) is a CompositorFrameSink is a or has a SurfaceFactory.
CompositorFrameSinks are created asynchronously and might live in another
process (the Mus / GPU process for example). My fear of this registration
approach for client IDs and SurfaceFactoryClients and so on is inherently racy
and not particularly cross-process friendly so I wanted to make it so that a
client ID exists as long as there exists a Surfacefactory for it.

The flow I'm imagining is:

1. Create the SurfaceFactory for the ui::Compositor.
2. Create the SurfaceFactory for the children
(DelegatedFrameHost/RenderWidgetHostViewChildFrame, etc).
3. Set up the hierarchy.

If a SurfaceFactory goes away then we can reap resources
(GarbageCollectSurfaces) for that client, for example. 

RegisterSurfaceClientId and RegisterSurfaceFactoryClient go away.

I don't think we need an explicit public RegisterBeginFrameSource API either,
that can happy when you register a hierarchy.

The reason I haven't been working upstream just yet is moving out
RegisterSurfaceClientId has proven to be a bit problematic because
SurfaceSequences immediately become invalid if the client hasn't been registered
yet.

Note that if SurfaceFactory is no longer tied to an OutputSurface then that
problem goes way for now. I'm still trying to convince myself there exists a
sane flow for a restartable display compositor.

[Fady Samuel, 2016-08-25 22:50:47]

On 2016/08/25 14:05:54, Fady Samuel wrote:
> On 2016/08/25 03:33:45, piman OOO back 2016-08-29 wrote:
> >
>
https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
> > File ui/compositor/compositor.cc (right):
> > 
> >
>
https://codereview.chromium.org/2270573002/diff/140001/ui/compositor/composit...
> > ui/compositor/compositor.cc:253:
> > context_factory_->GetSurfaceManager()->RegisterSurfaceNamespaceHierarchy(
> > On 2016/08/25 02:43:06, Fady Samuel wrote:
> > > This all kind of goes in the opposite direction of where I was hoping to
go.
> > > 
> > > I wanted to tie SurfaceFactory to a particular client and tie all this
> > > registration stuff to SurfaceFactory lifetime (creation and destruction).
> > > 
> > > Thus you can't register hierarchies until you have a SurfaceFactory.
> > 
> > Does the SurfaceFactory have to be tied to the OutputSurface? Couldn't it be
> > owned by GpuProcessTransportFactory (on a per-compositor basis) and
> > predate/outlive the OutputSurfaces?
> > 
> > > 
> > > We hope to pull SurfaceManager and SurfaceFactory (all display compositor
> > > things) into the gpu process for both tadpole and salamander and so I was
> > hoping
> > > to make this code more async friendly.
> > > 
> > > I've been prototyping this in jellyfish to convince myself it'll work and
> I'm
> > > pretty close to being convinced :-)
> > > 
> > > This is change in ui::Compositor blocking your CL?
> 
> Yes, you're right. SurfaceFactory can be pulled out of OutputSurface.
> 
> Some background: My current mental model (and you can kind of see this in
> jellyfish) is a CompositorFrameSink is a or has a SurfaceFactory.
> CompositorFrameSinks are created asynchronously and might live in another
> process (the Mus / GPU process for example). My fear of this registration
> approach for client IDs and SurfaceFactoryClients and so on is inherently racy
> and not particularly cross-process friendly so I wanted to make it so that a
> client ID exists as long as there exists a Surfacefactory for it.
> 
> The flow I'm imagining is:
> 
> 1. Create the SurfaceFactory for the ui::Compositor.
> 2. Create the SurfaceFactory for the children
> (DelegatedFrameHost/RenderWidgetHostViewChildFrame, etc).
> 3. Set up the hierarchy.
> 
> If a SurfaceFactory goes away then we can reap resources
> (GarbageCollectSurfaces) for that client, for example. 
> 
> RegisterSurfaceClientId and RegisterSurfaceFactoryClient go away.
> 
> I don't think we need an explicit public RegisterBeginFrameSource API either,
> that can happy when you register a hierarchy.
> 
> The reason I haven't been working upstream just yet is moving out
> RegisterSurfaceClientId has proven to be a bit problematic because
> SurfaceSequences immediately become invalid if the client hasn't been
registered
> yet.
> 
> Note that if SurfaceFactory is no longer tied to an OutputSurface then that
> problem goes way for now. I'm still trying to convince myself there exists a
> sane flow for a restartable display compositor.

With the above said, lgtm :P

[enne (OOO), 2016-08-25 23:11:17]

On 2016/08/25 at 14:05:54, fsamuel wrote:

> Some background: My current mental model (and you can kind of see this in
jellyfish) is a CompositorFrameSink is a or has a SurfaceFactory.
CompositorFrameSinks are created asynchronously and might live in another
process (the Mus / GPU process for example). My fear of this registration
approach for client IDs and SurfaceFactoryClients and so on is inherently racy
and not particularly cross-process friendly so I wanted to make it so that a
client ID exists as long as there exists a Surfacefactory for it.
> 
> The flow I'm imagining is:
> 
> 1. Create the SurfaceFactory for the ui::Compositor.
> 2. Create the SurfaceFactory for the children
(DelegatedFrameHost/RenderWidgetHostViewChildFrame, etc).
> 3. Set up the hierarchy.
> 
> If a SurfaceFactory goes away then we can reap resources
(GarbageCollectSurfaces) for that client, for example. 
> 
> RegisterSurfaceClientId and RegisterSurfaceFactoryClient go away.
> 
> I don't think we need an explicit public RegisterBeginFrameSource API either,
that can happy when you register a hierarchy.
> 
> The reason I haven't been working upstream just yet is moving out
RegisterSurfaceClientId has proven to be a bit problematic because
SurfaceSequences immediately become invalid if the client hasn't been registered
yet.

This all sounds reasonable to me.  The current set of registration functions are
a bit too verbose, and it'd be nice to simplify that.

SurfaceDisplayOutputSurface also doesn't need to be the SurfaceFactoryClient
itself.  That could easily live outside of it in GPTF.

[danakj, 2016-08-25 23:52:38]

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

[commit-bot: I haz the power, 2016-08-25 23:53:15]

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

[danakj, 2016-08-25 23:53:21]

This patch has 2 problems:

1) SingleThreadProxy was not setting output_surface_lost_ in
ReleaseOutputSurface() which means it would not try to make an output surface
when doing CompositeImmediately().

2) content unittests were using LTH::DidLoseOutputSurface which basically does
nothing now. What they wanted was to lose the output surface which is
ReleaseOutputSurface, so I made them do that instead and I'll look at removing
LTH::DidLoseOutputSurface.

[danakj, 2016-08-25 23:53:49]

On 2016/08/25 23:53:21, danakj wrote:
> This patch has 2 problems:
> 
> 1) SingleThreadProxy was not setting output_surface_lost_ in
> ReleaseOutputSurface() which means it would not try to make an output surface
> when doing CompositeImmediately().
> 
> 2) content unittests were using LTH::DidLoseOutputSurface which basically does
> nothing now. What they wanted was to lose the output surface which is
> ReleaseOutputSurface, so I made them do that instead and I'll look at removing
> LTH::DidLoseOutputSurface.

Hopefully bots are green now with those fixed.

[commit-bot: I haz the power, 2016-08-26 00:13:37]

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

[commit-bot: I haz the power, 2016-08-26 00:13:39]

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

[danakj, 2016-08-26 01:25:04]

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

[danakj, 2016-08-26 01:25:07]

Fady, I had to add a SurfaceManager to ui/views/mus/surface_context_factory for
the mash_unittests were crashing on a nullptr otherwise.

[commit-bot: I haz the power, 2016-08-26 01:25:25]

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

[nyquist, 2016-08-26 01:41:27]

blimp lgtm

[commit-bot: I haz the power, 2016-08-26 01:47:33]

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

[commit-bot: I haz the power, 2016-08-26 01:47:34]

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

[danakj, 2016-08-26 02:28:04]

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

[commit-bot: I haz the power, 2016-08-26 02:28:40]

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

[danakj, 2016-08-26 02:31:41]

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

[commit-bot: I haz the power, 2016-08-26 02:32:45]

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

[danakj, 2016-08-26 03:04:50]

Enne, annnd one more change. Yet another if (!lth->output_surface_lost()) guard
to ReleaseOutputSurface() on android made me consider that we should make it
cheaper to call this if it does nothing. So I made LTHI::ReleaseOutputSurface
early out if !output_surface_ since that means we don't have any resources etc
anyways. So why tree walk and stuff right?

[commit-bot: I haz the power, 2016-08-26 04:49:21]

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

[commit-bot: I haz the power, 2016-08-26 04:49:22]

Dry run: This issue passed the CQ dry run.

[danakj, 2016-08-26 18:13:09]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-08-26 18:13:10]

The patchset sent to the CQ was uploaded after l-g-t-m from junov@chromium.org,
enne@chromium.org, sadrul@chromium.org, fsamuel@chromium.org,
nyquist@chromium.org
Link to the patchset: https://codereview.chromium.org/2270573002/#ps220001
(title: "lth-outputsurface-lost: android-build-and-earlyout-sooner")

[commit-bot: I haz the power, 2016-08-26 18:14:26]

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-08-26 18:25:12]

Description was changed from

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

The only exception is SingleThreadProxy needs to know to request
and output surface when doing synchronous composite things. So it does
that itself now.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

The only exception is SingleThreadProxy needs to know to request
and output surface when doing synchronous composite things. So it does
that itself now.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[commit-bot: I haz the power, 2016-08-26 18:25:13]

Committed patchset #12 (id:220001)

[commit-bot: I haz the power, 2016-08-26 18:28:06]

Description was changed from

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

The only exception is SingleThreadProxy needs to know to request
and output surface when doing synchronous composite things. So it does
that itself now.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Get rid of LayerTreeHost::output_surface_lost_ state.

This was mostly tracked because while lost the main thread Renderer
capabilities would not be valid. However a few things have changed now:
1) No more renderer capabilities. So
2) We don't care if we main frame without an output surface.
3) We don't defer commits on the main thread so we wouldn't try to
start a frame on the main thread while the output surface is lost
anyways.

The only exception is SingleThreadProxy needs to know to request
and output surface when doing synchronous composite things. So it does
that itself now.

R=enne
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

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

[commit-bot: I haz the power, 2016-08-26 18:28:08]

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