DM: add --serialize

DM: add --serialize

Plus:
  - minor ReplayTask refactoring to share code with SerializeTask
  - move --replay to ReplayTask and --serialize to SerializeTask like WriteTask
  - when --writePath is given, write failures for Replay and Serialize tasks
  - function names have fewer blatant Skia style violations

BUG=

Committed: http://code.google.com/p/skia/source/detail?r=11890

[bsalomon, 2013-10-21 17:34:01]

https://codereview.chromium.org/32613003/diff/150001/dm/DMCpuTask.cpp
File dm/DMCpuTask.cpp (right):

https://codereview.chromium.org/32613003/diff/150001/dm/DMCpuTask.cpp#newcode36
dm/DMCpuTask.cpp:36: this->spawnChild(SkNEW_ARGS(ReplayTask, (*this,
fGMFactory(NULL), bitmap)));
Does this mean we always run replay and serialize now?

[mtklein, 2013-10-21 17:51:46]

https://codereview.chromium.org/32613003/diff/150001/dm/DMCpuTask.cpp
File dm/DMCpuTask.cpp (right):

https://codereview.chromium.org/32613003/diff/150001/dm/DMCpuTask.cpp#newcode36
dm/DMCpuTask.cpp:36: this->spawnChild(SkNEW_ARGS(ReplayTask, (*this,
fGMFactory(NULL), bitmap)));
On 2013/10/21 17:34:01, bsalomon wrote:
> Does this mean we always run replay and serialize now?

Not quite.  It means those tasks will always be created, which is negligible
cost compared to actually calling their draw() methods.

This change mimics WriteTask, which controls whether it does anything by looking
at --writePath in shouldSkip(); replay and serialize now check their
corresponding flag in shouldSkip() too.  Makes more sense in my head for
ReplayTask and SerializeTask to manage whether we should be doing the replay or
serialization instead of having that responsibility in CpuTask.  They all become
"do this if it makes sense" here.

[bsalomon, 2013-10-21 17:59:08]

On 2013/10/21 17:51:46, mtklein wrote:
> https://codereview.chromium.org/32613003/diff/150001/dm/DMCpuTask.cpp
> File dm/DMCpuTask.cpp (right):
> 
>
https://codereview.chromium.org/32613003/diff/150001/dm/DMCpuTask.cpp#newcode36
> dm/DMCpuTask.cpp:36: this->spawnChild(SkNEW_ARGS(ReplayTask, (*this,
> fGMFactory(NULL), bitmap)));
> On 2013/10/21 17:34:01, bsalomon wrote:
> > Does this mean we always run replay and serialize now?
> 
> Not quite.  It means those tasks will always be created, which is negligible
> cost compared to actually calling their draw() methods.
> 
> This change mimics WriteTask, which controls whether it does anything by
looking
> at --writePath in shouldSkip(); replay and serialize now check their
> corresponding flag in shouldSkip() too.  Makes more sense in my head for
> ReplayTask and SerializeTask to manage whether we should be doing the replay
or
> serialization instead of having that responsibility in CpuTask.  They all
become
> "do this if it makes sense" here.

Got it... I see where the tasks are checking the flag. lgtm.

[commit-bot: I haz the power, 2013-10-21 18:00:39]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/32613003/150001

[commit-bot: I haz the power, 2013-10-21 18:05:29]

Retried try job too often on Build-Ubuntu12-GCC-x86_64-Release-Trybot for
step(s) BuildBench, BuildEverything, BuildGm, BuildSkiaLib, BuildTests,
BuildTools
http://skiabot-master.pogerlabs.com:10117/buildstatus?builder=Build-Ubuntu12-...

[commit-bot: I haz the power, 2013-10-21 18:16:28]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/32613003/280001

[commit-bot: I haz the power, 2013-10-21 18:20:03]

Retried try job too often on Build-Mac10.7-Clang-x86-Release-Trybot for step(s)
BuildBench, BuildEverything, BuildGm, BuildSkiaLib, BuildTests, BuildTools
http://skiabot-master.pogerlabs.com:10117/buildstatus?builder=Build-Mac10.7-C...

[commit-bot: I haz the power, 2013-10-21 18:23:52]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/32613003/150002

[commit-bot: I haz the power, 2013-10-21 18:40:29]

Change committed as 11890