Also: do we already need this for the frame throughput web metric?

I think it depends on how we surface frame throughput to the web.

If we surface it based on frame durations, then yes, they'll need something to normalize against.

Alternatively, we could normalize the frame durations against the display frame rate before we give the data to the developer, in which case I don't think this would be necessary.

Good points. On first blush I would prefer we show things in (milli)seconds to keep things comparable and avoid surprises if the denominator (display frame rate) changes.

I agree with #3.

Do we have any idea how common non 60fps displays are?

I thought we had UMA for that but I only found these:

https://uma.googleplex.com/p/chrome/histograms/?endDate=08-16-2016&dayCount=1&histograms=Renderer4.CompositorThreadImplDrawDelay%2CScheduling.Browser.DrawInterval2&fixupData=true&showMax=true&filters=channel%2Ceq%2C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I think we still want this.