Bug 91692 – [chromium] Add histogram for tracking compositor-thread frame rate

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Nat Duca]

[chromium] Add histogram for tracking compositor-thread frame rate

[Nat Duca]

Created attachment 153130 [details]
Patch

[Adrienne Walker]

Comment on attachment 153130 [details]
Patch

What's the histogram for non-threaded mode?

[Nat Duca]

its in RenderWidget
either Renderer4.AccelDoDeferredUpdateDelay or Software

[Adrienne Walker]

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?

[Nat Duca]

Created attachment 153141 [details]
Patch

[Adrienne Walker]

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.

[Nat Duca]

Created attachment 153143 [details]
Patch

[Adrienne Walker]

(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.

[Nat Duca]

> 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.

[Adrienne Walker]

Comment on attachment 153143 [details]
Patch

R=me.

[WebKit Review Bot]

Comment on attachment 153143 [details]
Patch

Clearing flags on attachment: 153143

Committed r123056: <http://trac.webkit.org/changeset/123056>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.