Fix GPU tracing offset calculation on android.

Fix GPU tracing offset calculation on android.

The previous fix only made the offset calculation more stable, but
it still seems to race with when the device can go idle. I think
this is due to the trace command not being flushed. Since beginning
a trace is an asynchronous command, it is possible that the GPU can
still go idle after the we synchronize the timer because that is a
synchronous command. In order to guarantee that we are calculating
the offset after the asynchronous command has already begun, I have
made it so the offset is calculated before we issue the asynchronous
end trace call instead.

Technically this is still not completely fool proof because we can
have a case where we issue a trace begin and trace end immediately
and calculate the offset time before both commands are flushed, but
assuming we are actually tracing some GPU command that takes GPU time,
this should not happen very often.

BUG=None
TEST=local, trace a page for a minute.

Committed: https://crrev.com/c2bff8d3e630fb137b949a8cec45b79783b5d25e
Cr-Commit-Position: refs/heads/master@{#317164}

[David Yen, 2015-02-13 23:30:01]

dyen@chromium.org changed reviewers:
+ vmiura@chromium.org

[David Yen, 2015-02-13 23:30:02]

The previous fix did not fix it 100%, I think calculating the offset within the
trace before it ends is more reliable.

I suppose technically this can still be wrong if you start a trace and end a
trace without anything happening in between, but I don't know what we can do
about that case.

[David Yen, 2015-02-13 23:36:08]

dyen@chromium.org changed reviewers:
+ dcastagna@chromium.org

[David Yen, 2015-02-18 00:43:38]

On 2015/02/13 23:30:02, David Yen wrote:
> The previous fix did not fix it 100%, I think calculating the offset within
the
> trace before it ends is more reliable.
> 
> I suppose technically this can still be wrong if you start a trace and end a
> trace without anything happening in between, but I don't know what we can do
> about that case.

ping. I have updated the CL description to contain a more in depth description
of why this happens and what my fix does.

[Daniele Castagna, 2015-02-18 01:22:19]

LGTM.

There are still a few lines where g_fakeCPUTime is set to expect_start_time that
probably are not necessary anymore.

[David Yen, 2015-02-18 17:35:20]

On 2015/02/18 01:22:19, dcastagna wrote:
> LGTM.
> 
> There are still a few lines where g_fakeCPUTime is set to expect_start_time
that
> probably are not necessary anymore.

I think whenever we set the GL time we should also be setting the CPU time, the
unit tests should not be so implementation specific. I think it was a bug before
when we were not setting the CPU time and the GL time correctly.

[vmiura, 2015-02-19 23:09:36]

LGTM

[David Yen, 2015-02-19 23:16:50]

The CQ bit was checked by dyen@chromium.org

[commit-bot: I haz the power, 2015-02-19 23:18:28]

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

[commit-bot: I haz the power, 2015-02-19 23:22:34]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-02-19 23:23:20]

Patchset 3 (id:??) landed as
https://crrev.com/c2bff8d3e630fb137b949a8cec45b79783b5d25e
Cr-Commit-Position: refs/heads/master@{#317164}