Bug 91692

Summary: [chromium] Add histogram for tracking compositor-thread frame rate
Product: WebKit Reporter: Nat Duca <nduca>
Component: New BugsAssignee: Nat Duca <nduca>
Status: RESOLVED FIXED    
Severity: Normal CC: cc-bugs, enne, jamesr, webkit.review.bot, wiltzius
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Nat Duca
Reported 2012-07-18 16:24:02 PDT
[chromium] Add histogram for tracking compositor-thread frame rate
Attachments
Patch (1.96 KB, patch)
2012-07-18 16:26 PDT, Nat Duca 		no flags
DetailsFormatted DiffDiff
Patch (1.96 KB, patch)
2012-07-18 17:14 PDT, Nat Duca 		no flags
DetailsFormatted DiffDiff
Patch (2.03 KB, patch)
2012-07-18 17:18 PDT, Nat Duca 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Nat Duca
Comment 1 2012-07-18 16:26:10 PDT
Created attachment 153130 [details] Patch
Adrienne Walker
Comment 2 2012-07-18 16:37:49 PDT
Comment on attachment 153130 [details] Patch What's the histogram for non-threaded mode?
Nat Duca
Comment 3 2012-07-18 17:04:16 PDT
its in RenderWidget either Renderer4.AccelDoDeferredUpdateDelay or Software
Adrienne Walker
Comment 4 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?
Nat Duca
Comment 5 2012-07-18 17:14:24 PDT
Created attachment 153141 [details] Patch
Adrienne Walker
Comment 6 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.
Nat Duca
Comment 7 2012-07-18 17:18:13 PDT
Created attachment 153143 [details] Patch
Adrienne Walker
Comment 8 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.
Nat Duca
Comment 9 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.
Adrienne Walker
Comment 10 2012-07-18 17:24:44 PDT
Comment on attachment 153143 [details] Patch R=me.
WebKit Review Bot
Comment 11 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>
WebKit Review Bot
Comment 12 2012-07-18 18:08:41 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.