cc: Move task graph construction to RasterWorkerPool classes.

cc: Move task graph construction to RasterWorkerPool classes.

This removes the need to construct a temporary graph by
RasterWorkerPool classes. It reduces the number of tasks
created and eliminates the need for a dependencies vector
as part of the internal::WorkerPoolTask class.

This is also a prerequisite to implementing a "ready to activate"
signal as that requires as task graph structure that is not a tree.

BUG=247677
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207864

[reveman, 2013-06-18 15:12:49]

this is now ready for review

[vmpstr, 2013-06-19 00:18:26]

I like the fact that this simplifies worker pool by removing all of those
recursive functions for general task building.

That being said, it's a little bit awkward to me that there are two different
versions of insert raster task. One seems to just insert directly into the
graph, and one into a raster finished task. Do you think it's worth unifying
those in rwp (so that the code is physically near insert image decode), and just
having a dummy raster finished task for the image rwp? I might be mistaken about
the differences...

Ideally that code can even move somewhere else, like a util, since they are
statics anyway and right now the only reason they are in classes is that insert
raster calls insert image decode via inheritance. 

Aside from that, the code looks great. I'll take a closer look tomorrow.

[reveman, 2013-06-20 12:31:07]

Latest patch moves more logic to base RasterWorkerPool class by adding a
RasterTaskGraph class. PTAL.

[vmpstr, 2013-06-20 18:01:30]

I like this very much. So we end up just having graph.InsertRasterTask which
does it's own image decodes and everything.

lgtm.

https://codereview.chromium.org/17244003/diff/13001/cc/resources/raster_worke...
File cc/resources/raster_worker_pool.cc (right):

https://codereview.chromium.org/17244003/diff/13001/cc/resources/raster_worke...
cc/resources/raster_worker_pool.cc:465: ++schedule_raster_tasks_count_;
should this be incremented even if we schedule NULL? Or is this a signal that we
have to check for raster completed tasks again?

[reveman, 2013-06-20 18:34:09]

https://codereview.chromium.org/17244003/diff/13001/cc/resources/raster_worke...
File cc/resources/raster_worker_pool.cc (right):

https://codereview.chromium.org/17244003/diff/13001/cc/resources/raster_worke...
cc/resources/raster_worker_pool.cc:465: ++schedule_raster_tasks_count_;
On 2013/06/20 18:01:30, vmpstr wrote:
> should this be incremented even if we schedule NULL? Or is this a signal that
we
> have to check for raster completed tasks again?

we'll probably change this moving forward but I prefer to keep the existing
behavior in this patch.

[commit-bot: I haz the power, 2013-06-20 18:36:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/17244003/13001

[commit-bot: I haz the power, 2013-06-20 19:06:50]

Sorry for I got bad news for ya.
Compile failed with a clobber build on linux_chromeos_clang.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-06-21 02:01:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/17244003/13001

[commit-bot: I haz the power, 2013-06-21 02:52:26]

Sorry for I got bad news for ya.
Compile failed with a clobber build on win.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-06-21 14:47:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/17244003/38001

[commit-bot: I haz the power, 2013-06-21 16:52:52]

Change committed as 207864