Attempt at fixing color cube bench

Attempt at fixing color cube bench

The original bench was hitting the cache since it was using the same color filter for all loops. By creating a new color filter within the loop, at least this part of it is solved. I'm not 100% sure this is the right way, but at least the numbers are a bit more reasonable and are affected by the output resolution.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/12b1831ea49f3d88e93b7d2793d94852d03813e8

[sugoi1, 2014-10-09 18:18:21]

sugoi@chromium.org changed reviewers:
+ senorblanco@google.com

[sugoi1, 2014-10-09 18:18:21]

It's better this way. I'm not sure if it's perfect, but at least I get numbers
in the hundreds of nanoseconds rather than only a few nanoseconds.

[sugoi1, 2014-10-09 18:20:16]

sugoi@chromium.org changed reviewers:
+ mtklein@google.com, reed@google.com

[Stephen White, 2014-10-09 18:24:30]

senorblanco@chromium.org changed reviewers:
+ senorblanco@chromium.org

[Stephen White, 2014-10-09 18:24:30]

LGTM because it fixes a bot.

I'd like to dig deeper to figure out why the numbers are 
still so low, and don't scale with resolution. Could it be that the new overhead
is just that incurred by re-uploading the cube to texture every frame?

[sugoi1, 2014-10-09 18:27:25]

The CQ bit was checked by sugoi@chromium.org

[commit-bot: I haz the power, 2014-10-09 18:28:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/648483002/1

[reed1, 2014-10-09 18:30:17]

is the bench interested in profiling the cost of building the
internal-cube-representation, or drawing a bitmap w/ the filter applied.

The current fix seems like might spend a fair amount of time profiling the cost
of new/delete.

[commit-bot: I haz the power, 2014-10-09 18:35:15]

Committed patchset #1 (id:1) as 12b1831ea49f3d88e93b7d2793d94852d03813e8

[sugoi1, 2014-10-09 18:40:56]

On 2014/10/09 18:30:17, reed1 wrote:
> is the bench interested in profiling the cost of building the
> internal-cube-representation, or drawing a bitmap w/ the filter applied.
> 
> The current fix seems like might spend a fair amount of time profiling the
cost
> of new/delete.

Agreed. The issue I have is that the current bench only seems records gl
commands and stops the timer before actually drawing (glFlush() and
glSwpabuffers() being asynchronous calls, they don't wait for the drawing to
end, so the timer ends before the drawing does). Normally, I guess SkImageFilter
rendering causes a blit or something that forces it to wait on a glFlush, which
doesn't happen if all you have is a color filter (this needs more
investigation).

What happens currently is that the AutoTune phase of nanobench will clock this
effect at about 1 microsecond for an effect that renders at 2880x1800 and then
attempt to render it thousands of times, but even if the timer doesn't stop, the
drawing still has to happen at some point.

This cl merely increases the time it will take to render multiple colorcubes,
since no caching occurs, which will take hundreds of microsecs instead of only a
few nanosecs, which will prevent the bench from trying to render thousands of
times. I looked at ColorFilterBench, and it wraps the color filter inside an
image filter, but that seems like a lot of overhead. I'm not certain at the
moment what the proper solution is for this case...