cc: Report only on active tiles in tracing.

cc: Report only on active tiles in tracing.

This patch changes which tiles we report on. Previously, we logged
all of the available tiles. Now, we only log tiles that are active.
That is, only tiles that are on either active or pending trees are
logged.

The way this is done is as follows:
- Walk the tree, layers, tilings
- Insert all tiles from a tiling into a set
- Stuff those into a trace.

BUG=403094
Committed: https://crrev.com/d7de03c45e06e104e3ba022e240f7bc88315e753
Cr-Commit-Position: refs/heads/master@{#292183}

[vmpstr, 2014-08-19 23:06:42]

Please take a look.

[nduca, 2014-08-20 01:05:17]

lgtm with nit

https://codereview.chromium.org/493543002/diff/1/cc/trees/layer_tree_impl.h
File cc/trees/layer_tree_impl.h (right):

https://codereview.chromium.org/493543002/diff/1/cc/trees/layer_tree_impl.h#n...
cc/trees/layer_tree_impl.h:116: void AllTilesForTracingInto(std::set<const
Tile*>* tiles) const;
Should this be GetAll...

[enne (OOO), 2014-08-20 17:37:34]

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

https://codereview.chromium.org/493543002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:3230: tile_manager_->AllTilesAsValueInto(state,
tiles);
Something seems redundant here.  Why do you need to get tiles from both the
trees as well as the tile manager? It seems like you'd want either or?  Am I
misunderstanding what lives in TileManager's tile map these days?

[vmpstr, 2014-08-20 17:41:11]

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

https://codereview.chromium.org/493543002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:3230: tile_manager_->AllTilesAsValueInto(state,
tiles);
On 2014/08/20 17:37:34, enne wrote:
> Something seems redundant here.  Why do you need to get tiles from both the
> trees as well as the tile manager? It seems like you'd want either or?  Am I
> misunderstanding what lives in TileManager's tile map these days?

TileManager's tiles include recycled tiles (in fact, those are literally all the
tiles that have been created). Active/pending tree tiles are the ones that are
"in play" this frame. An alternative would be to plumb some sort of a
"IsTileOnActiveOrPendingTree" to tile manager via client which would search for
the tile in the trees, but this seems a more direct-ish approach.

[enne (OOO), 2014-08-20 18:05:43]

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

https://codereview.chromium.org/493543002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:3230: tile_manager_->AllTilesAsValueInto(state,
tiles);
On 2014/08/20 17:41:11, vmpstr wrote:
> On 2014/08/20 17:37:34, enne wrote:
> > Something seems redundant here.  Why do you need to get tiles from both the
> > trees as well as the tile manager? It seems like you'd want either or?  Am I
> > misunderstanding what lives in TileManager's tile map these days?
> 
> TileManager's tiles include recycled tiles (in fact, those are literally all
the
> tiles that have been created). Active/pending tree tiles are the ones that are
> "in play" this frame. An alternative would be to plumb some sort of a
> "IsTileOnActiveOrPendingTree" to tile manager via client which would search
for
> the tile in the trees, but this seems a more direct-ish approach.

Should the TileManager::AllTilesAsValueInto get removed, then?

[vmpstr, 2014-08-20 18:18:58]

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

https://codereview.chromium.org/493543002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:3230: tile_manager_->AllTilesAsValueInto(state,
tiles);
On 2014/08/20 18:05:42, enne wrote:
> On 2014/08/20 17:41:11, vmpstr wrote:
> > On 2014/08/20 17:37:34, enne wrote:
> > > Something seems redundant here.  Why do you need to get tiles from both
the
> > > trees as well as the tile manager? It seems like you'd want either or?  Am
I
> > > misunderstanding what lives in TileManager's tile map these days?
> > 
> > TileManager's tiles include recycled tiles (in fact, those are literally all
> the
> > tiles that have been created). Active/pending tree tiles are the ones that
are
> > "in play" this frame. An alternative would be to plumb some sort of a
> > "IsTileOnActiveOrPendingTree" to tile manager via client which would search
> for
> > the tile in the trees, but this seems a more direct-ish approach.
> 
> Should the TileManager::AllTilesAsValueInto get removed, then?

Hmm. Well, I don't really know. I feel like it's a good thing to log all the
tiles, even the recycle ones? I don't really have a justification for that
though. Nat, do you think these recycle tiles will ever be useful in trace
viewer? If not, I'll just remove the tile manager tile dump

[nduca, 2014-08-20 20:56:07]

lets just remove recycle tiles from the allTilesdump but update field names
accordingly --- liveTiles where we use tiles

[vmpstr, 2014-08-25 18:36:24]

On 2014/08/20 20:56:07, nduca wrote:
> lets just remove recycle tiles from the allTilesdump but update field names
> accordingly --- liveTiles where we use tiles

This would have to come with a traceviewer deps roll. Is that OK, or do we want
to keep the name the same for this patch?

[vmpstr, 2014-08-26 21:39:37]

PTAL.

This depends on https://codereview.appspot.com/132210043/, I'll include it in
deps once I know what the new traceviewer revision is.

[vmpstr, 2014-08-26 21:55:55]

On 2014/08/26 21:39:37, vmpstr wrote:
> PTAL.
> 
> This depends on https://codereview.appspot.com/132210043/, I'll include it in
> deps once I know what the new traceviewer revision is.

Actually, I put the deps roll separately in
https://codereview.chromium.org/507103002/ (so this now depends on that roll)

[nduca, 2014-08-27 15:59:55]

lgtm

[enne (OOO), 2014-08-27 16:52:58]

lgtm

[vmpstr, 2014-08-27 17:07:07]

The CQ bit was checked by vmpstr@chromium.org

[commit-bot: I haz the power, 2014-08-27 17:07:44]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/vmpstr@chromium.org/493543002/40001

[commit-bot: I haz the power, 2014-08-27 18:11:11]

Committed patchset #3 (id:40001) as 25c22c6adfafd8616592ea4866047b04913c4655

[commit-bot: I haz the power, 2014-09-10 02:52:42]

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