I'm not aware of regressions in the compositor. danakj@, could you please take a look?

Maybe it's not useful data.

// Deprecated because they combine Browser and Renderer stats and have low
// precision.
// TODO(brianderson): Remove.

https://cs.chromium.org/chromium/src/cc/scheduler/compositor_timing_history.cc?rcl=0&l=82

Handing this to Brian to triage as owner of the metric.

+rschoen and rkaplow as an FYI that this metric may not be useful anymore?

Hm, interesting. I think Sami had pointed me to this metric, any thoughts on the applicability of it?

Even more striking than the regression, the volume of data has gone down
https://uma.googleplex.com/timeline_v2?sid=c5a5c3e508a7ac68454cebf274730e5e 10X.

That's probably the underlying cause of the "regression"

Updating the name of the issue appropriately based on Comment 6. Will wait to here Sami's thoughts on the metric.

Oh - right, just remembered this is the metric that we downsamples. Didn't we have a bug about this already, where alexei pointed out the new bucket scheme will cause a shift in the metric?

A few comments:

Scheduling.Browser.DrawDuration is useful - it's Scheduling.DrawDuration that isn't. I'm working on removing it now.

It looks like the regression started before the reduced sampling rate landed, so I think that's a red herring.

Is there a list of Scheduling metrics CrOS is tracking? Although DrawDuration is an important sub metric, you probably want to track the 99th percentile of DrawInterval instead (for both Renderer and Browser) which is a more accurate picture of the compositor's frame rate.

Quick link to the 99% results from Stable for Linux, CrOS, Mac, Win, Android:
https://uma.googleplex.com/timeline_v2?sid=8221d5c226a0783dadcdfdf50047e795

There's a regression across the board in Browser.DrawDuration, but it doesn't appear to show up in Browser.DrawInterval.

The one bad thing about Browser.DrawInterval is that it won't include Browser animations that try to produce frames at less than 60fps since it looks like we keep going idle and that metric doesn't record an interval for the first frame coming out of an idle state. Not sure if that explains why there is a regression in DrawDuration but not DrawInterval.

Perhaps this is material design related, then. I think that's ChromeOS only. It may have animations at < 60hz.

MD is currently enabled on all desktop platforms.  The enable points have been staggered in time.  Without knowing what versions you're testing, I can't tell you if MD was only on for CrOS in those timeframes.

@briananderson - There's no formal list of metrics we are tracking at the moment. Ryan was kind enough to bring this to our attention when he was looking at some Chrome metrics. We are looking at tracking a consistent set of metrics, but that's a WIP atm.

My takeaway from what you're saying however, is that we shouldn't be too concerned w/ the DrawDuration regression as it hasn't manifested itself in DrawInterval? Or is there a concern that a further regression in this submetric or a related one could push things over a threshold such that we would then regress DrawInterval?

@msheets:
Correct. The general idea would be that DrawDuration should help narrow down the root cause if there's a regression in DrawInterval. It's weird though that there's no regression in DrawInterval here.

@pkasting:
Chrome Dev Browser.DrawDuration, by platform:
https://uma.googleplex.com/timeline_v2?sid=8c68af64f01da80b8168c6e0a9d1bd16

On dev, it looks like Windows, CrOS, and Linux all regressed around the same time in mid February.

Chrome Stable Browser.DrawDuration over time, by platform:
https://uma.googleplex.com/timeline_v2?sid=91eefd5f1a9e60d37d893146b664897a

On stable, It looks like the regression was staggered with Linux in mid April, then Windows followed quickly by CrOS in early May.

Does that coincide with material design?

@all:
Chrome Dev Browser+Renderer DrawDuration+Interval
https://uma.googleplex.com/timeline_v2?sid=b14c83cf5b3363732f774b0a64a58d71

In mid February, there wasn't the same kind of regression in Renderer.DrawDuration as Browser.DrawDuration, so a Browser content change like material design (rather than a change in the compositor itself) is probably what we are looking for.

Interestingly, there's a sharp regression on Windows at the end of April in both Renderer DrawDuration and DrawInterval without a change in the Browser. I've opened a  issue 619089  for that particular regression as it seems unrelated to this one.

That data doesn't sound like this is MD.  We didn't enable MD for Windows until just over a week ago, for example, while MD has been on for CrOS for a couple of months.

Are there any updates here? Looks like the regression is continuing.

Adding shrike, erikchen, ccameron. It seems too much like the DrawInterval regression on Mac to ignore...

On the Mac the DrawInterval regression seems to be due to clearing of IOSurfaces before reuse. IOSurfaces are Mac-only so this would not cause a regression on other platforms (I believe that is what you are wondering?). 

sadrul@, could you please help triage?