Bug 91692 - [chromium] Add histogram for tracking compositor-thread frame rate
Summary: [chromium] Add histogram for tracking compositor-thread frame rate
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nat Duca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 16:24 PDT by Nat Duca
Modified: 2012-07-18 18:08 PDT (History)
5 users (show)

See Also:


Attachments
Patch (1.96 KB, patch)
2012-07-18 16:26 PDT, Nat Duca
no flags Details | Formatted Diff | Diff
Patch (1.96 KB, patch)
2012-07-18 17:14 PDT, Nat Duca
no flags Details | Formatted Diff | Diff
Patch (2.03 KB, patch)
2012-07-18 17:18 PDT, Nat Duca
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nat Duca 2012-07-18 16:24:02 PDT
[chromium] Add histogram for tracking compositor-thread frame rate
Comment 1 Nat Duca 2012-07-18 16:26:10 PDT
Created attachment 153130 [details]
Patch
Comment 2 Adrienne Walker 2012-07-18 16:37:49 PDT
Comment on attachment 153130 [details]
Patch

What's the histogram for non-threaded mode?
Comment 3 Nat Duca 2012-07-18 17:04:16 PDT
its in RenderWidget
either Renderer4.AccelDoDeferredUpdateDelay or Software
Comment 4 Adrienne Walker 2012-07-18 17:14:14 PDT
Comment on attachment 153130 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153130&action=review

> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateCounter.cpp:65
> +        WebKit::Platform::current()->histogramCustomCounts("Renderer4.CompositorThreadImplDrawDelay", static_cast<int>(drawDelay), 1, 60, 30);

Isn't drawDelay in seconds?
Comment 5 Nat Duca 2012-07-18 17:14:24 PDT
Created attachment 153141 [details]
Patch
Comment 6 Adrienne Walker 2012-07-18 17:16:00 PDT
Comment on attachment 153141 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153141&action=review

> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateCounter.cpp:65
> +        WebKit::Platform::current()->histogramCustomCounts("Renderer4.CompositorThreadImplDrawDelay", static_cast<int>(drawDelay), 1, 120, 60);

Is there a reason not to use the same bucket spread as AccelDoDeferredUpdateDelay? The previous patch seemed better.
Comment 7 Nat Duca 2012-07-18 17:18:13 PDT
Created attachment 153143 [details]
Patch
Comment 8 Adrienne Walker 2012-07-18 17:21:35 PDT
(In reply to comment #6)
> (From update of attachment 153141 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=153141&action=review
> 
> > Source/WebCore/platform/graphics/chromium/cc/CCFrameRateCounter.cpp:65
> > +        WebKit::Platform::current()->histogramCustomCounts("Renderer4.CompositorThreadImplDrawDelay", static_cast<int>(drawDelay), 1, 120, 60);
> 
> Is there a reason not to use the same bucket spread as AccelDoDeferredUpdateDelay? The previous patch seemed better.

Same question applies to this latest patch.
Comment 9 Nat Duca 2012-07-18 17:23:49 PDT
> Is there a reason not to use the same bucket spread as AccelDoDeferredUpdateDelay? The previous patch seemed better.

Hehe yep.  I'm boosting the range on those in this changelist:
http://codereview.chromium.org/10802026/

Reason is, on those, with 0-60, 20% of the samples clip out at >60ms. I'd like to know how far that goes.
Comment 10 Adrienne Walker 2012-07-18 17:24:44 PDT
Comment on attachment 153143 [details]
Patch

R=me.
Comment 11 WebKit Review Bot 2012-07-18 18:08:36 PDT
Comment on attachment 153143 [details]
Patch

Clearing flags on attachment: 153143

Committed r123056: <http://trac.webkit.org/changeset/123056>
Comment 12 WebKit Review Bot 2012-07-18 18:08:41 PDT
All reviewed patches have been landed.  Closing bug.