(from triage): @cyanglaz @iskakaushik Do you still have plans for this PR?

@goderbauer Yes. I'll mark it as WIP until ready to review.

Desktop could introduce a few more variants. I know that 144Hz monitors are common.

As the number of "valid Hz" values increases, does having explicit fields become cumbersome? Should we introduce this as an array of values in some form? That would be troublesome for reporting, but how are we planning to report this? Is it a problem if a benchmark has the 60Hz frames go to 0? What if it is accompanied by an increase in 30Hz frames or 120Hz frames? Is this value mandated by the platform with no control? Or is it predicated on our success in being able to meet a given target and being rewarded with a faster frame rate as a result?

I guess I'm still not clear what our ultimate goal here is in collecting that data.

As the number of "valid Hz" values increases, does having explicit fields become cumbersome? Should we introduce this as an array of values in some form? That would be troublesome for reporting, but how are we planning to report this? Is it a problem if a benchmark has the 60Hz frames go to 0? What if it is accompanied by an increase in 30Hz frames or 120Hz frames? Is this value mandated by the platform with no control? Or is it predicated on our success in being able to meet a given target and being rewarded with a faster frame rate as a result?

I guess I'm still not clear what our ultimate goal here is in collecting that data.

Our short term goal with these values is to test if the newer iOS device can actually render in 120hz when we ask for it. See: https://docs.google.com/document/d/1O-ot6MydAl5pAr_XGnpR-Qq5A5CPDF6edaPu8xQtgCQ/edit?resourcekey=0-LlXeGtGRC67XL4NrGoc91A

So once we set our preferred frame rate to 120, ideally this benchmark should report with something like 90% (a make up number) of the frames are rendered in 120hz.

As the number of "valid Hz" values increases, does having explicit fields become cumbersome? Should we introduce this as an array of values in some form? That would be troublesome for reporting, but how are we planning to report this? Is it a problem if a benchmark has the 60Hz frames go to 0? What if it is accompanied by an increase in 30Hz frames or 120Hz frames? Is this value mandated by the platform with no control? Or is it predicated on our success in being able to meet a given target and being rewarded with a faster frame rate as a result?
I guess I'm still not clear what our ultimate goal here is in collecting that data.

Our short term goal with these values is to test if the newer iOS device can actually render in 120hz when we ask for it. See: https://docs.google.com/document/d/1O-ot6MydAl5pAr_XGnpR-Qq5A5CPDF6edaPu8xQtgCQ/edit?resourcekey=0-LlXeGtGRC67XL4NrGoc91A

So once we set our preferred frame rate to 120, ideally this benchmark should report with something like 90% (a make up number) of the frames are rendered in 120hz.

That sounds good, and note that my review approved the changes as is.

But I wonder if there isn't a more flexible way to report this so that we can report most frames are in some bucket without having to manually add new buckets as we go. Future phones may have even faster frame rates and the desktop world has all sorts of oddball in-between refresh rates available.

Gold has detected about 11 new digest(s) on patchset 4.
View them at https://flutter-gold.skia.org/cl/github/95699