cc: Fix DCHECK when impl thread changes scale on a layer being hidden.

cc: Fix DCHECK when impl thread changes scale on a layer being hidden.

If a layer is being hidden (no longer part of the
RenderSurfaceLayerList), then we will not UpdateTiles to add tilings to
it. If scales change on the active tree, the recycle tree will lose
its tilings, then the hidden layer will have 0 tilings on the pending
tree.

In this case, instead of keeping the non-ideal tilings on the active
tree, and having no high-res tiling, drop the non-ideal tilings from
the active tree.

R=enne, vmpstr
BUG=446751
Committed: https://crrev.com/72ab277eeae83cccf8ceddd42398b6bf4f943c69
Cr-Commit-Position: refs/heads/master@{#316368}

[enne (OOO), 2015-02-14 00:31:05]

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
File cc/resources/picture_layer_tiling_set.cc (right):

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
cc/resources/picture_layer_tiling_set.cc:69: // If the twin (pending) tiling set
is empty, for example it does not have
Are there any reasons why the active tree could still have valid content to be
showing but the pending twin has empty tilings?

[danakj, 2015-02-14 00:41:25]

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
File cc/resources/picture_layer_tiling_set.cc (right):

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
cc/resources/picture_layer_tiling_set.cc:69: // If the twin (pending) tiling set
is empty, for example it does not have
On 2015/02/14 00:31:05, enne wrote:
> Are there any reasons why the active tree could still have valid content to be
> showing but the pending twin has empty tilings?

We don't know what properties to use for the tilings. The tilings that are
currently on the active tree would be from then the last draw props happened
there. We have no valid live tiles rect or resolution to apply to those tilings
on activate.

I think you can construct a thing where the pending tree layer is not visible
but an animation will make it become visible at the same time you activate (a
race). Then the non-ideal tiling could in theory become useful there, if it
happened to be showing the same scale/position as the last active frame.

[enne (OOO), 2015-02-14 00:50:30]

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
File cc/resources/picture_layer_tiling_set.cc (right):

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
cc/resources/picture_layer_tiling_set.cc:69: // If the twin (pending) tiling set
is empty, for example it does not have
I guess I'm trying to say that I don't understand why you know that's the case
just because the pending set is empty.  Why don't you know?  I feel like I'm
missing something.

[danakj, 2015-02-14 00:52:20]

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
File cc/resources/picture_layer_tiling_set.cc (right):

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
cc/resources/picture_layer_tiling_set.cc:69: // If the twin (pending) tiling set
is empty, for example it does not have
On 2015/02/14 00:50:30, enne wrote:
> I guess I'm trying to say that I don't understand why you know that's the case
> just because the pending set is empty.  Why don't you know?  I feel like I'm
> missing something.

The pending set is empty means UpdateTiles didn't happen on the pending layer.
Cuz UpdateTiles always makes a high res tiling. I can say this in the comment if
you like.

[enne (OOO), 2015-02-14 00:53:14]

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
File cc/resources/picture_layer_tiling_set.cc (right):

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
cc/resources/picture_layer_tiling_set.cc:69: // If the twin (pending) tiling set
is empty, for example it does not have
On 2015/02/14 at 00:52:20, danakj wrote:
> On 2015/02/14 00:50:30, enne wrote:
> > I guess I'm trying to say that I don't understand why you know that's the
case
> > just because the pending set is empty.  Why don't you know?  I feel like I'm
> > missing something.
> 
> The pending set is empty means UpdateTiles didn't happen on the pending layer.
Cuz UpdateTiles always makes a high res tiling. I can say this in the comment if
you like.

Sure, but why does UpdateTiles not happening on the pending layer imply that
it's ok to remove everything from the active layer?

[danakj, 2015-02-14 00:56:13]

I modified the comment a bit, if that helps? Or maybe I'm missing the question's
point still.

[danakj, 2015-02-14 00:56:27]

Patchset #2 (id:20001) has been deleted

[danakj, 2015-02-14 00:57:38]

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
File cc/resources/picture_layer_tiling_set.cc (right):

https://codereview.chromium.org/924213002/diff/1/cc/resources/picture_layer_t...
cc/resources/picture_layer_tiling_set.cc:69: // If the twin (pending) tiling set
is empty, for example it does not have
On 2015/02/14 00:53:14, enne wrote:
> On 2015/02/14 at 00:52:20, danakj wrote:
> > On 2015/02/14 00:50:30, enne wrote:
> > > I guess I'm trying to say that I don't understand why you know that's the
> case
> > > just because the pending set is empty.  Why don't you know?  I feel like
I'm
> > > missing something.
> > 
> > The pending set is empty means UpdateTiles didn't happen on the pending
layer.
> Cuz UpdateTiles always makes a high res tiling. I can say this in the comment
if
> you like.
> 
> Sure, but why does UpdateTiles not happening on the pending layer imply that
> it's ok to remove everything from the active layer?

Ah. Well, the other choice is to leave behind a bunch of non-ideal tilings which
violates our expectations. We don't know which tiling would be high res.

When we activate, there was nothing visible in the pending tree that was part of
the requirements for activation. So there should not be anything on the active
tree that matters for the frame either.

[enne (OOO), 2015-02-14 01:00:03]

Oh, sorry, I missed the context where this was happening during activation.  In
that case, this makes total sense.  lgtm

[danakj, 2015-02-14 01:01:36]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-02-14 01:02:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/924213002/40001

[danakj, 2015-02-14 01:07:02]

The CQ bit was unchecked by danakj@chromium.org

[danakj, 2015-02-14 01:07:24]

New patchsets have been uploaded after l-g-t-m from enne@chromium.org

[danakj, 2015-02-14 01:07:32]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-02-14 01:07:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/924213002/60001

[commit-bot: I haz the power, 2015-02-14 01:11:08]

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

[commit-bot: I haz the power, 2015-02-14 01:11:09]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[danakj, 2015-02-14 01:37:15]

Patchset #3 (id:60001) has been deleted

[danakj, 2015-02-14 01:37:33]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-02-14 01:38:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/924213002/80001

[commit-bot: I haz the power, 2015-02-14 03:08:15]

Committed patchset #3 (id:80001)

[commit-bot: I haz the power, 2015-02-14 03:08:59]

Patchset 3 (id:??) landed as
https://crrev.com/72ab277eeae83cccf8ceddd42398b6bf4f943c69
Cr-Commit-Position: refs/heads/master@{#316368}