Expose synthetic delays through the GPU benchmarking extension

Expose synthetic delays through the GPU benchmarking extension

This patch makes it possible to use the GPU benchmarking extension to
configure synthetic delays. We add a new function with the following
signature:

    chrome.gpuBenchmarking.configureSyntheticDelay(
          name, target_duration, mode, callback)

where |name| is the delay point name, |target_duration| is the desired
delay point execution time, |mode| is one of "static", "oneshot" or
"alternating".

|callback| is invoked once all processes of the browser have
acknowledged the new delay setting.

BUG=307841

[Sami, 2013-11-22 18:49:26]

Here's the IPC for synthetic delay configuration. This is the part I'm least
happy about -- mainly because it's a lot of code :(

I thought of a plan B: configure the delays statically through the command line.
I think this should work for all the cases in our suite.

WDYT?

[nduca, 2013-11-24 19:41:53]

how about splitting up the part where we trigger it from the gpu bench extension
from the tracing controller part? the tracing controller part lgs, i think the
thing with the kickoff part is whether to do via rendering or maybe we could do
via devtools api. by splitting, we can land the stuff we know about and deal
with just the triggering change in isolation.

[nduca, 2013-11-24 19:42:00]

https://codereview.chromium.org/83483007/diff/1/content/browser/tracing/traci...
File content/browser/tracing/tracing_controller_impl.cc (right):

https://codereview.chromium.org/83483007/diff/1/content/browser/tracing/traci...
content/browser/tracing/tracing_controller_impl.cc:360: void
TracingControllerImpl::ConfigureSyntheticDelay(
i think you need to configure them all in one go, not one at a time. that'd take
a bit longer than I think is safe.

[Sami, 2013-12-02 12:26:03]

On 2013/11/24 19:42:00, nduca wrote:
> i think you need to configure them all in one go, not one at a time. that'd
take
> a bit longer than I think is safe.

Good point, done.

On 2013/11/24 19:41:53, nduca wrote:
> how about splitting up the part where we trigger it from the gpu bench
extension
> from the tracing controller part? the tracing controller part lgs, i think the
> thing with the kickoff part is whether to do via rendering or maybe we could
do
> via devtools api. by splitting, we can land the stuff we know about and deal
> with just the triggering change in isolation.

Yeah, that sounds like a more productive way forward. This patch is now all
about the gpu bencmarking & render widget part and the TracingController
plumbing is at https://codereview.chromium.org/98953002/. I'll try to sketch out
what the devtools path could look like.