12012-02-01 Alex Nicolaou <anicolao@chromium.org>
2
3 [chromium] When rendering goes idle, do not count that time against frame rate
4 https://bugs.webkit.org/show_bug.cgi?id=73454
5
6 The FPS counter had a few issues with its reporting. The first
7 3 swapbuffers are non-blocking and create FPS rates that are
8 unrealistically high, throwing off the moving averages and
9 introducing false spikes into the FPS graph. There was also no
10 way to monitor the smoothness of the animation, or to focus in
11 on a particular animation or transition.
12
13 This patch updates the FPS counter code so that bad data points
14 are trimmed and not graphed; so that the graph itself is taller
15 and more legible; so that there is a clear boundary between 40FPS
16 and better; so that outlier data points are labelled with their
17 frame rate so that you can see how slow the frame is that is
18 causing the jank; and to keep statistics on frame rate between
19 pauses in the activity in the UI so that you can trigger a
20 transition and read off the average and standard deviation for
21 that transition to judge it smooth enough or not.
22
23
24 Reviewed by NOBODY (OOPS!).
25
26 HUD is not testable in webkit.
27
28 * platform/graphics/chromium/cc/CCHeadsUpDisplay.cpp:
29 (WebCore::CCHeadsUpDisplay::CCHeadsUpDisplay):
30 (WebCore::CCHeadsUpDisplay::onFrameBegin):
31 (WebCore::CCHeadsUpDisplay::drawHudContents):
32 (WebCore::CCHeadsUpDisplay::drawFPSCounter):
33 * platform/graphics/chromium/cc/CCHeadsUpDisplay.h:
34