diff options
author | ericrk <ericrk@chromium.org> | 2016-03-24 13:03:13 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2016-03-24 20:04:35 +0000 |
commit | c38d1f4bce5165b0114fc9c429812e93f64850bf (patch) | |
tree | 133dcf1d3646099e599f1595c5df85de60715815 /cc | |
parent | 81b94784b431b36441e4b34fe3fc429db5be5e7a (diff) | |
download | chromium_src-c38d1f4bce5165b0114fc9c429812e93f64850bf.zip chromium_src-c38d1f4bce5165b0114fc9c429812e93f64850bf.tar.gz chromium_src-c38d1f4bce5165b0114fc9c429812e93f64850bf.tar.bz2 |
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
Review URL: https://codereview.chromium.org/1796423002
Cr-Commit-Position: refs/heads/master@{#383126}
Diffstat (limited to 'cc')
-rw-r--r-- | cc/tiles/tile_manager.cc | 20 |
1 files changed, 14 insertions, 6 deletions
diff --git a/cc/tiles/tile_manager.cc b/cc/tiles/tile_manager.cc index e950484..fa93c3d2 100644 --- a/cc/tiles/tile_manager.cc +++ b/cc/tiles/tile_manager.cc @@ -197,11 +197,15 @@ void InsertNodesForRasterTask(TaskGraph* graph, return node.task == decode_task; }); - // Tasks are inserted in priority order, so existing decode tasks should - // already be FOREGROUND if this is a high priority task. - DCHECK(decode_it == graph->nodes.end() || !high_priority || - static_cast<uint16_t>(TASK_CATEGORY_FOREGROUND) == - decode_it->category); + // In rare circumstances, a low priority task may come in before a high + // priority task. In these cases, upgrade any low-priority dependencies of + // the current task. + // TODO(ericrk): Task iterators should be updated to avoid this. + // crbug.com/594851 + if (decode_it != graph->nodes.end() && high_priority && + decode_it->category != decode_task_category) { + decode_it->category = decode_task_category; + } if (decode_it == graph->nodes.end()) { InsertNodeForTask(graph, decode_task, decode_task_category, priority, 0u); @@ -772,8 +776,12 @@ void TileManager::ScheduleTasks( all_count++; graph_.edges.push_back(TaskGraph::Edge(task, all_done_task.get())); + // A tile is high priority if it is either blocking future compositing + // (required for draw or required for activation), or if it has a priority + // bin of NOW for another reason (low resolution tiles). bool high_priority = - tile->required_for_draw() || tile->required_for_activation(); + tile->required_for_draw() || tile->required_for_activation() || + prioritized_tile.priority().priority_bin == TilePriority::NOW; InsertNodesForRasterTask(&graph_, task, task->dependencies(), priority++, use_gpu_rasterization_, high_priority); } |