Handle out of order tile priorities when building graph

Handle out of order tile priorities when building graph

Currently, InsertNodesForRasterTask in tile_manager.cc assumes that
all high priority tasks will be added before low priority ones. This is
generally true, but two cases violate this:
- low resolution tiles in the NOW bin may have higher priority than
  other tiles that are required for draw/activation.
- some SOON tiles not required for activation may come before SOON
  tiles which are required for activation. (bug files)

To address the first issue, the calculation of high_priority now takes
the NOW bucket into account. To fix the second issue,
InsertNodesForRasterTask now handles out-of-order priorities and a bug
has been filed to fix this.

BUG=592160
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/c38d1f4bce5165b0114fc9c429812e93f64850bf
Cr-Commit-Position: refs/heads/master@{#383126}

[ericrk, 2016-03-15 01:03:38]

Description was changed from

==========
Handle out of order tile priorities when building graph

Currently, InsertNodesForRasterTask in tile_manager.cc assumes that
all high priority tasks will be added before low priority ones. This is
generally true, but two cases violate this:
- low resolution tiles in the NOW bin may have higher priority than
  other tiles that are required for draw/activation.
- some SOON tiles not required for activation may come before SOON
  tiles which are required for activation. (bug files)

To address the first issue, the calculation of high_priority now takes
the NOW bucket into account. To fix the second issue,
InsertNodesForRasterTask now handles out-of-order priorities and a bug
has been filed to fix this.

BUG=592160
==========

to

==========
Handle out of order tile priorities when building graph

Currently, InsertNodesForRasterTask in tile_manager.cc assumes that
all high priority tasks will be added before low priority ones. This is
generally true, but two cases violate this:
- low resolution tiles in the NOW bin may have higher priority than
  other tiles that are required for draw/activation.
- some SOON tiles not required for activation may come before SOON
  tiles which are required for activation. (bug files)

To address the first issue, the calculation of high_priority now takes
the NOW bucket into account. To fix the second issue,
InsertNodesForRasterTask now handles out-of-order priorities and a bug
has been filed to fix this.

BUG=592160
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[ericrk, 2016-03-15 01:09:12]

ericrk@chromium.org changed reviewers:
+ vmpstr@chromium.org

[ericrk, 2016-03-21 16:42:49]

ping. Thanks!

[vmpstr, 2016-03-21 19:44:51]

lgtm with nits

https://codereview.chromium.org/1796423002/diff/20001/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/1796423002/diff/20001/cc/tiles/tile_manager.c...
cc/tiles/tile_manager.cc:204: decode_it->category !=
static_cast<uint16_t>(decode_task_category)) {
Why is static_cast required here? (and not below?)

https://codereview.chromium.org/1796423002/diff/20001/cc/tiles/tile_manager.c...
cc/tiles/tile_manager.cc:776: // (requierd for draw or required for activation),
or if it has a priority
s/requierd/required/

[ericrk, 2016-03-24 17:56:05]

https://codereview.chromium.org/1796423002/diff/20001/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/1796423002/diff/20001/cc/tiles/tile_manager.c...
cc/tiles/tile_manager.cc:204: decode_it->category !=
static_cast<uint16_t>(decode_task_category)) {
On 2016/03/21 19:44:50, vmpstr wrote:
> Why is static_cast required here? (and not below?)

I guess it's not... I must not have checked :D

https://codereview.chromium.org/1796423002/diff/20001/cc/tiles/tile_manager.c...
cc/tiles/tile_manager.cc:776: // (requierd for draw or required for activation),
or if it has a priority
On 2016/03/21 19:44:51, vmpstr wrote:
> s/requierd/required/

Done.

[ericrk, 2016-03-24 17:56:15]

The CQ bit was checked by ericrk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-24 17:56:39]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1796423002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1796423002/40001

[vmpstr, 2016-03-24 18:00:57]

lgtm thanks

[commit-bot: I haz the power, 2016-03-24 19:05:27]

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

[commit-bot: I haz the power, 2016-03-24 19:05:28]

Dry run: This issue passed the CQ dry run.

[ericrk, 2016-03-24 19:52:57]

The CQ bit was checked by ericrk@chromium.org

[commit-bot: I haz the power, 2016-03-24 19:53:37]

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

[commit-bot: I haz the power, 2016-03-24 20:03:29]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-03-24 20:04:47]

Description was changed from

==========
Handle out of order tile priorities when building graph

Currently, InsertNodesForRasterTask in tile_manager.cc assumes that
all high priority tasks will be added before low priority ones. This is
generally true, but two cases violate this:
- low resolution tiles in the NOW bin may have higher priority than
  other tiles that are required for draw/activation.
- some SOON tiles not required for activation may come before SOON
  tiles which are required for activation. (bug files)

To address the first issue, the calculation of high_priority now takes
the NOW bucket into account. To fix the second issue,
InsertNodesForRasterTask now handles out-of-order priorities and a bug
has been filed to fix this.

BUG=592160
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Handle out of order tile priorities when building graph

Currently, InsertNodesForRasterTask in tile_manager.cc assumes that
all high priority tasks will be added before low priority ones. This is
generally true, but two cases violate this:
- low resolution tiles in the NOW bin may have higher priority than
  other tiles that are required for draw/activation.
- some SOON tiles not required for activation may come before SOON
  tiles which are required for activation. (bug files)

To address the first issue, the calculation of high_priority now takes
the NOW bucket into account. To fix the second issue,
InsertNodesForRasterTask now handles out-of-order priorities and a bug
has been filed to fix this.

BUG=592160
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/c38d1f4bce5165b0114fc9c429812e93f64850bf
Cr-Commit-Position: refs/heads/master@{#383126}
==========

[commit-bot: I haz the power, 2016-03-24 20:04:48]

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