Move TaskGraph creation to TileManager

This change moves TaskGraph creation and management of
task set finished callbacks to TileManager. This logic was nearly
identical in all TileTaskRunners at this point.

We do lose a bit of tracing data from OneCopyTileTaskWorkerPool,
we can re-create this data by adding a new method to
TaskGraphRunner, but it seemed redundant with the memory
infra tracing data, so it seemed OK to drop.

BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/95ca56bc5de767ce231a8fe3b7fe2644942a94a4
Cr-Commit-Position: refs/heads/master@{#362874}

[ericrk, 2015-11-25 19:49:23]

Description was changed from

==========
factor schedule tasks


fixes for android and linux.

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

to

==========
This change moves TaskGraph creation and management of
task set finished callbacks to TileManager. This logic was nearly
identical in all TileTaskRunners at this point.

We do lose a bit of tracing data from OneCopyTileTaskWorkerPool,
we can re-create this data by adding a new method to
TaskGraphRunner, but it seemed redundant with the memory
infra tracing data, so it seemed OK to drop.

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

[ericrk, 2015-11-25 19:49:23]

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

[ericrk, 2015-11-25 19:49:39]

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_wo...
File cc/raster/tile_task_worker_pool_unittest.cc (left):

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_wo...
cc/raster/tile_task_worker_pool_unittest.cc:395: // Don't append any tasks, just
call ScheduleTasks.
This no longer applies and is very similar to the existing
TileManagerTest::AllWorkFinished.

[reveman, 2015-11-26 00:18:30]

Some comments related to additional cleanup which would be fine to do as a
follow up if you prefer that.

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
File cc/raster/tile_task_runner.h (right):

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
cc/raster/tile_task_runner.h:32: class CC_EXPORT TileTask : public Task {
All these task classes were needed for async uploads but we should be able to
remove all that now. TileManager can just create basic Tasks for everything.

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
cc/raster/tile_task_runner.h:81: class CC_EXPORT TileTaskRunner {
This interface doesn't really provide anything but raster buffers at this point.
I'd like to see this become something like RasterBufferProvider without all the
scheduling stuff. TileTaskClient basically but with GetResourceFormat+
GetResourceRequiresSwizzle.

https://codereview.chromium.org/1470113002/diff/180001/cc/tiles/tile_manager.h
File cc/tiles/tile_manager.h (right):

https://codereview.chromium.org/1470113002/diff/180001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:95: using TaskSetCollection =
std::bitset<kNumberOfTaskSets>;
Can we get rid of all this and just build the correct task graph based on
Tile::required_for_activation() etc directly.

[ericrk, 2015-11-30 23:52:16]

Thanks for the feedback - have a few questions.

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
File cc/raster/tile_task_runner.h (right):

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
cc/raster/tile_task_runner.h:32: class CC_EXPORT TileTask : public Task {
On 2015/11/26 00:18:30, reveman wrote:
> All these task classes were needed for async uploads but we should be able to
> remove all that now. TileManager can just create basic Tasks for everything.

Don't we still need Schedule/CompleteOnOriginThread? These are used by all our
tasks.

Also, we still use ImageDecodeTasks and RasterTasks? can you explain a bit more?

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
cc/raster/tile_task_runner.h:81: class CC_EXPORT TileTaskRunner {
On 2015/11/26 00:18:30, reveman wrote:
> This interface doesn't really provide anything but raster buffers at this
point.
> I'd like to see this become something like RasterBufferProvider without all
the
> scheduling stuff. TileTaskClient basically but with GetResourceFormat+
> GetResourceRequiresSwizzle.

Are you suggesting moving the scheduling logic to TileManager? Seems mostly OK,
but there's still some logic in GPU/OneCopy w.r.t. ordering barriers? Although
that could be handled in a different way.

https://codereview.chromium.org/1470113002/diff/180001/cc/tiles/tile_manager.h
File cc/tiles/tile_manager.h (right):

https://codereview.chromium.org/1470113002/diff/180001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:95: using TaskSetCollection =
std::bitset<kNumberOfTaskSets>;
On 2015/11/26 00:18:30, reveman wrote:
> Can we get rid of all this and just build the correct task graph based on
> Tile::required_for_activation() etc directly.

this is more used for tracking which task sets are completed across all tasks
for firing callbacks, not really in construction. We can simplify this a bit
though (combine with the NamedTaskSet below).

[ericrk, 2015-12-02 02:28:29]

I think I understand most of what you're suggesting here - I'm going to push
most of this to follow up CLs, but I did get rid of a bit more in this CL. Let
me know if this sounds good.

[reveman, 2015-12-02 05:22:55]

I would prefer to see the TaskSet code removed as I think it makes for a simpler
patch but I'm fine with that as a follow-up if you insist.

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
File cc/raster/tile_task_runner.h (right):

https://codereview.chromium.org/1470113002/diff/180001/cc/raster/tile_task_ru...
cc/raster/tile_task_runner.h:81: class CC_EXPORT TileTaskRunner {
On 2015/11/30 at 23:52:16, ericrk wrote:
> On 2015/11/26 00:18:30, reveman wrote:
> > This interface doesn't really provide anything but raster buffers at this
point.
> > I'd like to see this become something like RasterBufferProvider without all
the
> > scheduling stuff. TileTaskClient basically but with GetResourceFormat+
> > GetResourceRequiresSwizzle.
> 
> Are you suggesting moving the scheduling logic to TileManager? Seems mostly
OK, but there's still some logic in GPU/OneCopy w.r.t. ordering barriers?
Although that could be handled in a different way.

Yea, but let's save that for a follow up.

https://codereview.chromium.org/1470113002/diff/180001/cc/tiles/tile_manager.h
File cc/tiles/tile_manager.h (right):

https://codereview.chromium.org/1470113002/diff/180001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:95: using TaskSetCollection =
std::bitset<kNumberOfTaskSets>;
On 2015/11/30 at 23:52:16, ericrk wrote:
> On 2015/11/26 00:18:30, reveman wrote:
> > Can we get rid of all this and just build the correct task graph based on
> > Tile::required_for_activation() etc directly.
> 
> this is more used for tracking which task sets are completed across all tasks
for firing callbacks, not really in construction. We can simplify this a bit
though (combine with the NamedTaskSet below).

I'm thinking that we just get rid of all this task set stuff now that that's no
longer forced on us as a result of living behind the TileTaskRunner interface
that is unaware of concepts such as activation, etc.

For example to keep track of what tasks have finished running we'd just use 3
bools:

bool tasks_required_for_activation_pending_;
bool tasks_required_for_draw_pending_;
bool tasks_pending_;

I think this would make for code that is much easier to understand and it
matches the interface exposed by the Tile class. e.g. there's a
Tile::required_for_activation() getter and not a Tile::task_sets() getter.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:256: scoped_refptr<TileTask> CreateTaskSetFinishedTask(
I'm generally not a fan of factory functions that does nothing more than add a
make_scoped_ptr/refptr. Is this function really useful?

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:383: void
TileManager::DidFinishRunningTileTasks(TaskSet task_set) {
I think this would be much cleaner refactored as three different functions
instead of one function with enum and a switch statement.
DidFinishRunningTileTasksRequiredForActivation, etc.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:731: scoped_ptr<TaskGraph> graph(new TaskGraph);
Before this we've swapped between two task graphs which we allowed to grow as
needed to minimize heap allocations each time we schedule a new graph. Those
heap allocations used to take ~50% of the time when scheduling a graph so it's
probably a good idea to keep doing that.

To be consistent with the TaskGraphRunner interface I suggest that
TileTaskRunner also takes raw pointer to a TaskGraph instead of a scoped_ptr and
ownership so that you can do this swap-between-two-graphs optimization here in
TM.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:732: std::array<scoped_refptr<TileTask>,
kNumberOfTaskSets>
are we allowed to use std::array now?

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:752: // TaskGraphRunner may be using them.
They only need to be kept alive while scheduled. I think I would be prefer
explicit required_for_activation_finished_task_,
required_for_draw_finished_task_... members for this that we reset here. Wdyt?

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager.h
File cc/tiles/tile_manager.h (left):

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:315: TileTaskQueue raster_queue_;
Keep this as "TaskGraph task_graph_"? See my other comment about avoiding heap
allocations.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager.h
File cc/tiles/tile_manager.h (right):

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:98: // PixelBufferTileTaskWorkerPool depends on ALL
being last.
not sure we need this enum still but we should at least remove this comment.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:101: // tile_task_runner.h
and this one

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:291: std::array<scoped_refptr<TileTask>,
kNumberOfTaskSets>*
The code that had to deal with task sets in the past was not aware of the exact
meaning of them but that's not the case now that this is implemented here. Can
we just pass 3 raw pointers to Tasks instead of this array and all the use of
kNumberOfTaskSets?

Task* required_for_activation_finished_task,
Task* required_for_draw_finished_task,
Task* finished_task
....

btw, are we allowed to use std::array in chromium now?

[ericrk, 2015-12-02 21:28:09]

Thanks for the feedback!

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:256: scoped_refptr<TileTask> CreateTaskSetFinishedTask(
On 2015/12/02 05:22:55, reveman wrote:
> I'm generally not a fan of factory functions that does nothing more than add a
> make_scoped_ptr/refptr. Is this function really useful?

restructured things a bit - the function still exists, but is a bit more useful.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:383: void
TileManager::DidFinishRunningTileTasks(TaskSet task_set) {
On 2015/12/02 05:22:54, reveman wrote:
> I think this would be much cleaner refactored as three different functions
> instead of one function with enum and a switch statement.
> DidFinishRunningTileTasksRequiredForActivation, etc.

Done.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:731: scoped_ptr<TaskGraph> graph(new TaskGraph);
On 2015/12/02 05:22:54, reveman wrote:
> Before this we've swapped between two task graphs which we allowed to grow as
> needed to minimize heap allocations each time we schedule a new graph. Those
> heap allocations used to take ~50% of the time when scheduling a graph so it's
> probably a good idea to keep doing that.
> 
> To be consistent with the TaskGraphRunner interface I suggest that
> TileTaskRunner also takes raw pointer to a TaskGraph instead of a scoped_ptr
and
> ownership so that you can do this swap-between-two-graphs optimization here in
> TM.

from looking at the old code, it seems that we only need one graph, and to call
the Reset fn? Updated this to match the previous behavior (no new graphs).

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:732: std::array<scoped_refptr<TileTask>,
kNumberOfTaskSets>
On 2015/12/02 05:22:54, reveman wrote:
> are we allowed to use std::array now?

yup, went through the process of getting that approved, it's now in the style
guide... not useful anymore though :P

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:752: // TaskGraphRunner may be using them.
On 2015/12/02 05:22:54, reveman wrote:
> They only need to be kept alive while scheduled. I think I would be prefer
> explicit required_for_activation_finished_task_,
> required_for_draw_finished_task_... members for this that we reset here. Wdyt?

re-structured things along these lines.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager.h
File cc/tiles/tile_manager.h (right):

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:98: // PixelBufferTileTaskWorkerPool depends on ALL
being last.
On 2015/12/02 05:22:55, reveman wrote:
> not sure we need this enum still but we should at least remove this comment.

removed.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:101: // tile_task_runner.h
On 2015/12/02 05:22:55, reveman wrote:
> and this one

Done.

https://codereview.chromium.org/1470113002/diff/220001/cc/tiles/tile_manager....
cc/tiles/tile_manager.h:291: std::array<scoped_refptr<TileTask>,
kNumberOfTaskSets>*
On 2015/12/02 05:22:55, reveman wrote:
> The code that had to deal with task sets in the past was not aware of the
exact
> meaning of them but that's not the case now that this is implemented here. Can
> we just pass 3 raw pointers to Tasks instead of this array and all the use of
> kNumberOfTaskSets?
> 
> Task* required_for_activation_finished_task,
> Task* required_for_draw_finished_task,
> Task* finished_task
> ....
> 
> btw, are we allowed to use std::array in chromium now?

std::array is now allowed.

Re structured this - the tasks are now member vars.

[reveman, 2015-12-02 22:26:05]

lgtm with some nits and optional suggestions

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/bitmap_tile_...
File cc/raster/bitmap_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/bitmap_tile_...
cc/raster/bitmap_tile_task_worker_pool.h:65: TaskGraph* graph_;
Do we need to keep a pointer to this here? If we do, then how do we know that
the tile manager has not modified or destroyed it?

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/gpu_tile_tas...
File cc/raster/gpu_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/gpu_tile_tas...
cc/raster/gpu_tile_task_worker_pool.h:64: TaskGraph* graph_;
ditto

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/one_copy_til...
File cc/raster/one_copy_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/one_copy_til...
cc/raster/one_copy_tile_task_worker_pool.h:143: TaskGraph* graph_;
ditto

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/zero_copy_ti...
File cc/raster/zero_copy_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/zero_copy_ti...
cc/raster/zero_copy_tile_task_worker_pool.h:70: TaskGraph* graph_;
ditto

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:406: "state", ScheduledTasksStateAsValue());
can we call this directly in DidFinishRunningTileTasksRequiredForActivation and
DidFinishRunningTileTasksRequiredForDraw?

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:408: TRACE_EVENT_ASYNC_END0("cc", "ScheduledTasks",
this);
and this directly in DidFinishRunningAllTileTasks and remove this
DidFinishRunningAnyTileTasks helper function?

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:714: scoped_refptr<TileTask> old_all_done_task;
nit: how about "scoped_refptr<TileTask> new_*_done_task" here and then
"*_done_task_ = new_*_done_task_" after ScheduleTasks call and avoid all the
std::swap-ing? I think that would be a bit easier to understand.

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:1052: }
nit: would it not be easier to read if this helper was removed and the code was
just inlined below? up to you

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:1070:
CreateTaskSetFinishedTask(&TileManager::DidFinishRunningAllTileTasks);
ah, I see why you did the std::swap in the other function now. would it not be
easier to create those tasks by the caller and just pass raw pointers to them to
this function? I think I'd perfer that but either way is fine with me

[ericrk, 2015-12-03 00:43:22]

Thanks again - lots of stuff to clean up here :D

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/bitmap_tile_...
File cc/raster/bitmap_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/bitmap_tile_...
cc/raster/bitmap_tile_task_worker_pool.h:65: TaskGraph* graph_;
On 2015/12/02 22:26:05, reveman wrote:
> Do we need to keep a pointer to this here? If we do, then how do we know that
> the tile manager has not modified or destroyed it?

heh - we don't any more - this was just keeping the graph alive (which is now
handled elsewhere) - removed.

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/gpu_tile_tas...
File cc/raster/gpu_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/gpu_tile_tas...
cc/raster/gpu_tile_task_worker_pool.h:64: TaskGraph* graph_;
On 2015/12/02 22:26:05, reveman wrote:
> ditto

Done.

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/one_copy_til...
File cc/raster/one_copy_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/one_copy_til...
cc/raster/one_copy_tile_task_worker_pool.h:143: TaskGraph* graph_;
On 2015/12/02 22:26:05, reveman wrote:
> ditto

Done.

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/zero_copy_ti...
File cc/raster/zero_copy_tile_task_worker_pool.h (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/raster/zero_copy_ti...
cc/raster/zero_copy_tile_task_worker_pool.h:70: TaskGraph* graph_;
On 2015/12/02 22:26:05, reveman wrote:
> ditto

Done.

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:406: "state", ScheduledTasksStateAsValue());
On 2015/12/02 22:26:05, reveman wrote:
> can we call this directly in DidFinishRunningTileTasksRequiredForActivation
and
> DidFinishRunningTileTasksRequiredForDraw?

yup - that makes sense.

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:408: TRACE_EVENT_ASYNC_END0("cc", "ScheduledTasks",
this);
On 2015/12/02 22:26:05, reveman wrote:
> and this directly in DidFinishRunningAllTileTasks and remove this
> DidFinishRunningAnyTileTasks helper function?

Done.

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:714: scoped_refptr<TileTask> old_all_done_task;
On 2015/12/02 22:26:05, reveman wrote:
> nit: how about "scoped_refptr<TileTask> new_*_done_task" here and then
> "*_done_task_ = new_*_done_task_" after ScheduleTasks call and avoid all the
> std::swap-ing? I think that would be a bit easier to understand.

restructured things to avoid this.

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:1052: }
On 2015/12/02 22:26:05, reveman wrote:
> nit: would it not be easier to read if this helper was removed and the code
was
> just inlined below? up to you

Done.

https://codereview.chromium.org/1470113002/diff/280001/cc/tiles/tile_manager....
cc/tiles/tile_manager.cc:1070:
CreateTaskSetFinishedTask(&TileManager::DidFinishRunningAllTileTasks);
On 2015/12/02 22:26:05, reveman wrote:
> ah, I see why you did the std::swap in the other function now. would it not be
> easier to create those tasks by the caller and just pass raw pointers to them
to
> this function? I think I'd perfer that but either way is fine with me

Inlined this function, so it's no longer an issue - got rid of the swap stuff.

[ericrk, 2015-12-03 00:43:31]

The CQ bit was checked by ericrk@chromium.org

[ericrk, 2015-12-03 00:43:32]

The patchset sent to the CQ was uploaded after l-g-t-m from reveman@chromium.org
Link to the patchset: https://codereview.chromium.org/1470113002/#ps300001
(title: "feedback")

[commit-bot: I haz the power, 2015-12-03 00:45:11]

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

[commit-bot: I haz the power, 2015-12-03 02:54:25]

Description was changed from

==========
This change moves TaskGraph creation and management of
task set finished callbacks to TileManager. This logic was nearly
identical in all TileTaskRunners at this point.

We do lose a bit of tracing data from OneCopyTileTaskWorkerPool,
we can re-create this data by adding a new method to
TaskGraphRunner, but it seemed redundant with the memory
infra tracing data, so it seemed OK to drop.

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

to

==========
This change moves TaskGraph creation and management of
task set finished callbacks to TileManager. This logic was nearly
identical in all TileTaskRunners at this point.

We do lose a bit of tracing data from OneCopyTileTaskWorkerPool,
we can re-create this data by adding a new method to
TaskGraphRunner, but it seemed redundant with the memory
infra tracing data, so it seemed OK to drop.

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

[commit-bot: I haz the power, 2015-12-03 02:54:26]

Committed patchset #16 (id:300001)

[commit-bot: I haz the power, 2015-12-03 02:55:22]

Description was changed from

==========
This change moves TaskGraph creation and management of
task set finished callbacks to TileManager. This logic was nearly
identical in all TileTaskRunners at this point.

We do lose a bit of tracing data from OneCopyTileTaskWorkerPool,
we can re-create this data by adding a new method to
TaskGraphRunner, but it seemed redundant with the memory
infra tracing data, so it seemed OK to drop.

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

to

==========
This change moves TaskGraph creation and management of
task set finished callbacks to TileManager. This logic was nearly
identical in all TileTaskRunners at this point.

We do lose a bit of tracing data from OneCopyTileTaskWorkerPool,
we can re-create this data by adding a new method to
TaskGraphRunner, but it seemed redundant with the memory
infra tracing data, so it seemed OK to drop.

BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/95ca56bc5de767ce231a8fe3b7fe2644942a94a4
Cr-Commit-Position: refs/heads/master@{#362874}
==========

[commit-bot: I haz the power, 2015-12-03 02:55:23]

Patchset 16 (id:??) landed as
https://crrev.com/95ca56bc5de767ce231a8fe3b7fe2644942a94a4
Cr-Commit-Position: refs/heads/master@{#362874}