Let SkBenchmark subclasses specify that they do no rendering

By default SkBenchmark sets fIsRendering to true.
Subclasses can set it to false in their constructor.

If !fIsRendering, the benchmark only executes for one config, whether we specify one or all configs (8888, 565, GPU, NULLGPU).

This change gives a 15-20% speedup on bench cycle time. I suspect there are more benchmark suites that could be flagged as non-rendering for a bit more speedup.

As long as we're driving the bench graphs with a consistent set of configs, we'll see these always show up on the same set (8888).

[TomH, 2012-09-12 09:34:34]

Why yes, New and Improved Skia is now 20% faster according to independent
scientific tests.

https://codereview.appspot.com/6500115/diff/1/bench/benchmain.cpp
File bench/benchmain.cpp (right):

https://codereview.appspot.com/6500115/diff/1/bench/benchmain.cpp#newcode746
bench/benchmain.cpp:746: runOnce = true;
Instead of adding the bool, we could check
  (!bench->isRendering() && x > 0)

[TomH, 2012-09-13 15:01:25]

...adding still more reviewers - hopefully this now hits *everybody* who has
*ever* paid attention to benchmarks?

[reed1, 2012-09-13 15:03:06]

lgtm

[bsalomon, 2012-09-13 15:03:56]

On 2012/09/13 15:01:25, TomH wrote:
> ...adding still more reviewers - hopefully this now hits *everybody* who has
> *ever* paid attention to benchmarks?

Should we have a special config name associated with non-rendering tests rather
than always associating them with the first config run?

[TomH, 2012-09-13 15:07:45]

On 2012/09/13 15:03:56, bsalomon wrote:
> Should we have a special config name associated with non-rendering tests
rather
> than always associating them with the first config run?

That sort of question is why I had the infrastructure & graphing people on the
CL & mentioned it in the description.

[epoger, 2012-09-13 15:44:00]

LGTM

On 2012/09/13 15:07:45, TomH wrote:
> On 2012/09/13 15:03:56, bsalomon wrote:
> > Should we have a special config name associated with non-rendering tests
> rather
> > than always associating them with the first config run?

I think it's fine the way it is.  This way, we'll keep graphing the results
automatically.

> 
> That sort of question is why I had the infrastructure & graphing people on the
> CL & mentioned it in the description.

I think the large number of reviewers triggered
http://en.wikipedia.org/wiki/Diffusion_of_responsibility

[TomH, 2012-09-13 15:51:14]

On 2012/09/13 15:44:00, epoger wrote:
> I think the large number of reviewers triggered
> http://en.wikipedia.org/wiki/Diffusion_of_responsibility

Yep.

Closed with r5525.