telemetry: Update Android frame latency metrics

telemetry: Update Android frame latency metrics

Update the Android SurfaceFlinger-based frame latency metrics to match
the numbers that are tracked downstream. The new method records the time
of the most recent vsync when a new frame is submitted to SurfaceFlinger.
These frame timestamps are used to derive the following animation quality
indicators:

  1. Average frame rate (avg_surface_fps).

  2. Maximum time between frames (max_frame_delay) in number elapsed
     vsync periods.

  3. Number of "janks" or dropped frames during the benchmark
     (jank_count). This is calculated by first taking the frame
     durations:

        duration[i] = timestamp[i + 1] - timestamp[i]

     and then seeing when the duration changes:

        changes[i] = duration[i + 1] - duration[i]

     Every time the frame duration increases by an additional vsync
     interval multiple we count the frame as jank:

        jank_count = sum{1 | max(0, round(changes[i] / vsync_interval)) > 0}

BUG=https://b/8364918


Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=189006

[Sami, 2013-03-18 18:17:05]

This makes our jank metrics comparable with downstream. PTAL.

[bulach, 2013-03-18 18:45:03]

lgtm, thanks!

small suggestion below, feel free to ignore if it doesn't improve...

also, nit: this is not just for telemetry, so maybe just:
"Android: update frame latency metrics" as the title?

https://codereview.chromium.org/12438022/diff/1/build/android/pylib/surface_s...
File build/android/pylib/surface_stats_collector.py (right):

https://codereview.chromium.org/12438022/diff/1/build/android/pylib/surface_s...
build/android/pylib/surface_stats_collector.py:87: for change in length_changes]
not sure if it'd be any more readable, but it seems we'd avoid an extra local
(length_changes) by extracting:

@staticmethod
def _GetNormalizedDeltas(data, refresh_period):
  deltas = [t2 - t1 for t1, t2 in zip(data, data[1:])]
  return (deltas, [delta / refresh_period for delta in deltas])

then:
frame_lengths, normalized_frame_lengths = _GetNormalizedDeltas(timestamps,
refresh_period)
_, normalized_changes = _GetNormalizedDeltas(frame_lengths, refresh_period)

[Sami, 2013-03-18 19:03:15]

https://codereview.chromium.org/12438022/diff/1/build/android/pylib/surface_s...
File build/android/pylib/surface_stats_collector.py (right):

https://codereview.chromium.org/12438022/diff/1/build/android/pylib/surface_s...
build/android/pylib/surface_stats_collector.py:87: for change in length_changes]
That's much more readable, thanks!

[Tom Hudson, 2013-03-19 09:27:51]

The Android metrics I'm spotting in bug reports are:

Average Number of Jankiness	 1.7000
Max Number of Jankiness	 3
Average Frame Rate	 59.2231
Max Number of Accumulated Frames	 2.5000

It looks like this CL is only giving us two of those?
And it isn't clear how your jank_count maps to their average/max number of
jankiness stats.

[Sami, 2013-03-19 10:55:44]

On 2013/03/19 09:27:51, Tom Hudson wrote:
> The Android metrics I'm spotting in bug reports are:
> 
> Average Number of Jankiness	 1.7000
> Max Number of Jankiness	 3
> Average Frame Rate	 59.2231
> Max Number of Accumulated Frames	 2.5000
> 
> It looks like this CL is only giving us two of those?
> And it isn't clear how your jank_count maps to their average/max number of
> jankiness stats.

It's not entirely clear from looking at the downstream implementation of this
either (see bug). Basically the downstream test records three numbers for each
run: jankiness count, max accumulated frames and frame rate. I think the four
numbers you see in the reports are derived from these over several runs. Since
we're recording the same figures, our dashboard should be able to derive the
same numbers -- with the exception that we get the averages over several builds
instead of a single build.

[Tom Hudson, 2013-03-19 11:02:47]

On 2013/03/19 10:55:44, Sami wrote:
> It's not entirely clear from looking at the downstream implementation of this
> either (see bug). Basically the downstream test records three numbers for each
> run: jankiness count, max accumulated frames and frame rate. I think the four
> numbers you see in the reports are derived from these over several runs. Since
> we're recording the same figures, our dashboard should be able to derive the
> same numbers -- with the exception that we get the averages over several
builds
> instead of a single build.

That makes sense. LGTM.

[commit-bot: I haz the power, 2013-03-19 11:27:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/skyostil@chromium.org/12438022/9001

[commit-bot: I haz the power, 2013-03-19 13:41:10]

Change committed as 189006