cc: Ensure to return pending now before active eventually tiles.

cc: Ensure to return pending now before active eventually tiles.

This patch is part 2 of a fix to return pending now tiles before active
eventually tiles. We already do this at a pair level. This patch ensures
that we also do it across pairs. That is, given two pairs of layers,
if the highest priority tile on one is an active eventually tile and
the highest priority tile on the other is a pending now tile, then
prefer the pending now tile (this is just for smoothness).

This ensures that we activate if we're prepainting too far.

BUG=426287
R=reveman

Committed: https://crrev.com/806cad8d08a0414928b04e6a8635c1ddc35a91db
Cr-Commit-Position: refs/heads/master@{#300981}

[vmpstr, 2014-10-23 08:12:34]

PTAL

[reveman, 2014-10-23 21:01:42]

lgtm

https://codereview.chromium.org/675663002/diff/60001/cc/resources/raster_tile...
File cc/resources/raster_tile_priority_queue.cc (right):

https://codereview.chromium.org/675663002/diff/60001/cc/resources/raster_tile...
cc/resources/raster_tile_priority_queue.cc:77: }
This function is already kind of hard to read. Any ideas for how it can be
cleaned up long term? Can we move some of this logic into the TilePriority?

[vmpstr, 2014-10-23 22:01:48]

https://codereview.chromium.org/675663002/diff/60001/cc/resources/raster_tile...
File cc/resources/raster_tile_priority_queue.cc (right):

https://codereview.chromium.org/675663002/diff/60001/cc/resources/raster_tile...
cc/resources/raster_tile_priority_queue.cc:77: }
On 2014/10/23 21:01:42, reveman wrote:
> This function is already kind of hard to read. Any ideas for how it can be
> cleaned up long term? Can we move some of this logic into the TilePriority?

That's a good idea. I agree that it's a bit not trivial to do. I'll file a bug
to track this. I want to get a good solid story for all tree priorities and tile
priority combinations and the order in which we will return tiles (and I want it
to be somewhat explicit in the code, easy to change, etc). 

That can be a nice iterators follow-up.

[vmpstr, 2014-10-23 22:01:51]

The CQ bit was checked by vmpstr@chromium.org

[commit-bot: I haz the power, 2014-10-23 22:03:27]

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

[vmpstr, 2014-10-23 22:09:47]

On 2014/10/23 22:01:48, vmpstr wrote:
>
https://codereview.chromium.org/675663002/diff/60001/cc/resources/raster_tile...
> File cc/resources/raster_tile_priority_queue.cc (right):
> 
>
https://codereview.chromium.org/675663002/diff/60001/cc/resources/raster_tile...
> cc/resources/raster_tile_priority_queue.cc:77: }
> On 2014/10/23 21:01:42, reveman wrote:
> > This function is already kind of hard to read. Any ideas for how it can be
> > cleaned up long term? Can we move some of this logic into the TilePriority?
> 
> That's a good idea. I agree that it's a bit not trivial to do. I'll file a bug
> to track this. I want to get a good solid story for all tree priorities and
tile
> priority combinations and the order in which we will return tiles (and I want
it
> to be somewhat explicit in the code, easy to change, etc). 
> 
> That can be a nice iterators follow-up.

Err, not trivial to read.

[commit-bot: I haz the power, 2014-10-23 23:36:02]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2014-10-23 23:36:57]

Patchset 4 (id:??) landed as
https://crrev.com/806cad8d08a0414928b04e6a8635c1ddc35a91db
Cr-Commit-Position: refs/heads/master@{#300981}

[vmpstr, 2014-10-27 15:53:26]

Patchset #5 (id:80001) has been deleted