cc: Fix incorrect LTHI shutdown logic

cc: Fix incorrect LTHI shutdown logic

It's possible that if there has never been an activation (implying no root
layer on the active tree), then the trees will not be cleared during
LayerTreeHostImpl's destructor.  Given the comment in the destructor about
animation, this seems to be problematic enough.

Issue 251722 is about a case where the tile manager tries to activate the tree
during its destruction but because the trees haven't been cleared yet, it
thinks this is a supported operation.  This is fixed by always destroying the
trees in the destructor.

Related cleanup is to remove the CleanupRenderSurfaces() call which isn't
needed there.  When you destroy a tree, you destroy its render surfaces.  And,
it looked like none of the other CleanupRenderSurfaces() calls were really
needed either except for losing the output surface, so one call got moved there
and all the rest of the functions got removed.

[email protected]
BUG=251722
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=209242

[enne (OOO), 2013-06-20 00:15:22]

This may seem like overkill cleanup, but this function has been on my radar
before as being unnecessary.

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (left):

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:230: ClearRenderSurfaces();
This call seems unneeded since the trees are about to be destroyed.

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:1390: recycle_tree_->ClearRenderSurfaces();
This call is also unneeded.  There's no reason to do extra work to delete these
here.  The layers all still exist and we'll reuse or clean them up as needed the
next time we do a CalculateDrawProperties.

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:1449: ClearRenderSurfaces();
Why would we only do this if there's a root layer?? This seems like a mistake
waiting to happen too.  Moving this per-layer call into
SendDidLoseOutputSurfaceRecursive seems like a much better option.

[danakj, 2013-06-20 00:46:05]

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:2105: current->ClearRenderSurface();
This actually seems weird to do at all! What does a lost context have to do with
this? It used to hold a texture but it does not now.

If we really want to do this, we should clear all draw properties.. WDYT of just
removing this?

[enne (OOO), 2013-06-20 00:51:31]

Good catch!  I forgot that render surface resources were not owned by the
surfaces anymore.

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/16831016/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:2105: current->ClearRenderSurface();
On 2013/06/20 00:46:06, danakj wrote:
> This actually seems weird to do at all! What does a lost context have to do
with
> this? It used to hold a texture but it does not now.
> 
> If we really want to do this, we should clear all draw properties.. WDYT of
just
> removing this?

Done.

[danakj, 2013-06-20 00:54:10]

Cool, LGTM++

[danakj, 2013-06-20 00:54:51]

+boliu fyi

[boliu, 2013-06-20 01:41:21]

Looks like this is going to collide midair with
https://codereview.chromium.org/16700003/ in layer_tree_host_impl.cc

Should I hold off mine? It's not blocking anything for webview

[commit-bot: I haz the power, 2013-06-20 01:43:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16831016/5001

[commit-bot: I haz the power, 2013-06-20 03:38:10]

Retried try job too often on linux_rel for step(s) cc_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[danakj, 2013-06-20 15:04:20]

On Wed, Jun 19, 2013 at 9:41 PM, <[email protected]> wrote:

> Looks like this is going to collide midair with
>
https://codereview.chromium.**org/16700003/<https://codereview.chromium.org/1...
layer_tree_host_impl.cc
>
> Should I hold off mine? It's not blocking anything for webview
>

enne's OOO and this didn't land, you should go ahead IMO.


>
>
https://codereview.chromium.**org/16831016/<https://codereview.chromium.org/1...
>

[Yaron, 2013-06-20 18:00:37]

On 2013/06/20 15:04:20, danakj wrote:
> On Wed, Jun 19, 2013 at 9:41 PM, <mailto:[email protected]> wrote:
> 
> > Looks like this is going to collide midair with
> >
>
https://codereview.chromium.**org/16700003/%3Chttps://codereview.chromium.org...
> layer_tree_host_impl.cc
> >
> > Should I hold off mine? It's not blocking anything for webview
> >
> 
> enne's OOO and this didn't land, you should go ahead IMO.
> 
> 
> >
> >
>
https://codereview.chromium.**org/16831016/%3Chttps://codereview.chromium.org...>
> >

On the other hand we're considering this as a fix for 28. Can we get this in
first since it presumably makes merging easier?

[danakj, 2013-06-20 21:20:53]

On Thu, Jun 20, 2013 at 2:00 PM, <[email protected]> wrote:

> On 2013/06/20 15:04:20, danakj wrote:
>
>  On Wed, Jun 19, 2013 at 9:41 PM, <mailto:[email protected]> wrote:
>>
>
>  > Looks like this is going to collide midair with
>> >
>>
>
> https://codereview.chromium.****org/16700003/%3Chttps://codere**
>
view.chromium.org/16700003/%**3Ein<http://codereview.chromium.org/16700003/%3Ein>
>
>  layer_tree_host_impl.cc
>> >
>> > Should I hold off mine? It's not blocking anything for webview
>> >
>>
>
>  enne's OOO and this didn't land, you should go ahead IMO.
>>
>
>
>  >
>> >
>>
>
> https://codereview.chromium.****org/16831016/%3Chttps://codere**
> view.chromium.org/16831016/ <http://codereview.chromium.org/16831016/>>
>
>> >
>>
>
> On the other hand we're considering this as a fix for 28. Can we get this
> in
> first since it presumably makes merging easier?
>

I would say the merging isn't significantly harder as bo's CL just moves
the callsite. If this was my CL I'd say don't block on it.


>
>
https://codereview.chromium.**org/16831016/<https://codereview.chromium.org/1...
>

[boliu, 2013-06-20 22:21:28]

Well, mine already went in. I wasn't added to the cc list so didn't see any of
these replies until now.

I think the actual fix is only in the destructor of LHTI, right? I can upload
that bit which should not (?) have merge conflicts in m28

[commit-bot: I haz the power, 2013-06-27 23:02:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16831016/31005

[commit-bot: I haz the power, 2013-06-29 00:06:10]

Retried try job too often on win_rel for step(s) chrome_frame_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-06-29 00:20:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16831016/31005

[commit-bot: I haz the power, 2013-06-29 00:24:13]

Change committed as 209242