cc: Rework how picture layer tiling set gets into raster queues.

cc: Rework how picture layer tiling set gets into raster queues.

This patch changes several things to make caching tiles slightly more
contained:

1. Register picture layer tiling sets with tile manager directly.
2. Maintained paired layer tiling sets in tile manager instead of
   pairing things every time we need to build a queue
3. Change the iterators to work with paired tiling sets.

R=danakj, enne, reveman@chromium.org

[vmpstr, 2015-02-05 00:52:31]

PTAL. Sorry about a big patch. I haven't really reviewed this myself, so feel
free to put this on the backburner until I ping :P

[vmpstr, 2015-02-07 00:54:59]

PTAL, I've rebased this. Let me know if you think any part of it should be a
separate CL, but it's kind of all dependent of each other I think.

[enne (OOO), 2015-02-10 21:28:31]

https://codereview.chromium.org/900073003/diff/40001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:605: if (layer_tree_impl()->tile_manager()) {
When can you not have a TileManager during this call?

https://codereview.chromium.org/900073003/diff/40001/cc/resources/raster_tile...
File cc/resources/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/resources/raster_tile...
cc/resources/raster_tile_priority_queue_all.cc:158: if (active &&
!active->HasValidTilePriorities())
Would it make sense to unregister/register when there aren't valid tile
priorities vs checking every time?  I don't feel strongly about that, but am
curious what you think.

https://codereview.chromium.org/900073003/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:266: void
TileManager::RegisterPictureLayerTilingSet(
This is way better than building pairs every time.  Is there any perf
improvement, or is this just a cleanup?

[vmpstr, 2015-02-11 21:37:16]

PTAL.

https://codereview.chromium.org/900073003/diff/40001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:605: if (layer_tree_impl()->tile_manager()) {
On 2015/02/10 21:28:31, enne wrote:
> When can you not have a TileManager during this call?

Several unittests aren't too happy without this if. I think the reason is that
we can call ReleaseResources/delete tile manager during InitializeRenderer, but
then fail to bind the surface to the client and early out. This means we never
RecreatedResources or create a new tile manager, but then later we try again to
set a new output surface, which would again call ReleaseResources (and crash
here).

TLDR: we can call ReleaseResources multiple times before calling
RecreateResources, depending on how smoothly everything goes in LTHI.

https://codereview.chromium.org/900073003/diff/40001/cc/resources/raster_tile...
File cc/resources/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/resources/raster_tile...
cc/resources/raster_tile_priority_queue_all.cc:158: if (active &&
!active->HasValidTilePriorities())
On 2015/02/10 21:28:31, enne wrote:
> Would it make sense to unregister/register when there aren't valid tile
> priorities vs checking every time?  I don't feel strongly about that, but am
> curious what you think.

We process non-valid-tile-priority layers in eviction iterators though. Also,
this would just add an extra register/unregister pair that i'm trying really
hard to avoid :)

https://codereview.chromium.org/900073003/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:266: void
TileManager::RegisterPictureLayerTilingSet(
On 2015/02/10 21:28:31, enne wrote:
> This is way better than building pairs every time.  Is there any perf
> improvement, or is this just a cleanup?

This is meant to be a cleanup, but I'll get some perf numbers tomorrow.

[enne (OOO), 2015-02-11 21:46:16]

https://codereview.chromium.org/900073003/diff/40001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:605: if (layer_tree_impl()->tile_manager()) {
On 2015/02/11 21:37:16, vmpstr wrote:
> On 2015/02/10 21:28:31, enne wrote:
> > When can you not have a TileManager during this call?
> 
> Several unittests aren't too happy without this if. I think the reason is that
> we can call ReleaseResources/delete tile manager during InitializeRenderer,
but
> then fail to bind the surface to the client and early out. This means we never
> RecreatedResources or create a new tile manager, but then later we try again
to
> set a new output surface, which would again call ReleaseResources (and crash
> here).
> 
> TLDR: we can call ReleaseResources multiple times before calling
> RecreateResources, depending on how smoothly everything goes in LTHI.

Ok! Thanks for the explanation.

https://codereview.chromium.org/900073003/diff/40001/cc/resources/raster_tile...
File cc/resources/raster_tile_priority_queue_all.cc (right):

https://codereview.chromium.org/900073003/diff/40001/cc/resources/raster_tile...
cc/resources/raster_tile_priority_queue_all.cc:158: if (active &&
!active->HasValidTilePriorities())
On 2015/02/11 21:37:16, vmpstr wrote:
> On 2015/02/10 21:28:31, enne wrote:
> > Would it make sense to unregister/register when there aren't valid tile
> > priorities vs checking every time?  I don't feel strongly about that, but am
> > curious what you think.
> 
> We process non-valid-tile-priority layers in eviction iterators though. Also,
> this would just add an extra register/unregister pair that i'm trying really
> hard to avoid :)

Aha, ok! That makes sense.

[enne (OOO), 2015-02-11 23:05:44]

lgtm