Created a bisect request for this:
https://crosperf-dev.googleplex.com/b/2695b797-ac5c-44e0-8a75-2324c2130c47

https://crosperf.googleplex.com/b/21655b33-b52f-4441-ac86-6b4d0681c6e8

video_PlaybackPerf.vp8.1080.60fps/sw_video_dropped_frames_vp8_1080p_60fps
regressed from 0 to 25 (lower is better)
  https://crosbolt.teams.x20web.corp.google.com/prod/crosbolt/time_series/video_PlaybackPerf.vp8.1080.60fps/sw_video_dropped_frames_vp8_1080p_60fps.html?from_version=72.11246.0.0&to_version=73.11599.0.0&y_min=-13.368406285072965&y_max=189.00058560897884&sku_filter=kefka%7Clars%7Cpyro%7Crobo_%7Csetzer%7Csnappy%7Cterra%7Cwinky
https://screenshot.googleplex.com/N7OVxxy3qLV.png
This is not pyro only.

According to our bisect result,
 https://crosperf.googleplex.com/b/4ea1999e-13ef-43c4-8cce-59a857f3f4f9
the regression is introduced by this CL since R72-11289.0.0
https://chromium.googlesource.com/chromium/src.git/+/10d7fc3b763a758374e0dfc74d5fd9d36bc1b146
  [Ozone DRM] Don't round refresh rate for PresentationFeedback

kylechar, could you please take a look?


p.s.  issue 923199  is another regression with the same CL but is minnie only

So similar to  crbug.com/923199 , my CL was to fix b/116769488 where arc++ was running at ~100fps instead of ~60fps. I had changed how the refresh rate was plumbed out of the display compositor and the refresh rate was getting rounded to an integer instead of using the floating point value. Somehow changing refresh rate from 59.47hz to 60hz was causing things to run at ~100fps.

https://crrev.com/c/1230578 is where I broke the refresh rate values for some boards. It was only some boards because there are three cases before this change:
1. The float refresh rate and integer refresh rate were equal then it didn't matter.
2. The float and integer refresh rates aren't equal. SetAuthoritativeVsyncInterval() arrived at the right time and the correct float refresh rate was used.
3. The float and integer refresh rates aren't equal. SetAuthoritativeVsyncInterval() arrived too early and the integer refresh rate was being used.

I did my original testing on cave and noticed that SetAuthorativeVsyncInterval() wasn't doing anything. This test on cave seems to confirm that it falls into case 3, it was using integer refresh rate in M70 already (lower dropped frames). It's in M71 stable (merged back) and M72+ that has the float refresh rate (higher dropped frames).

https://crosbolt.teams.x20web.corp.google.com/prod/crosbolt/time_series/video_PlaybackPerf.vp8.1080.60fps/sw_video_dropped_frames_vp8_1080p_60fps.html?num_versions=-1&sku_filter=cave&y_max=189.00058560897884&y_min=-13.368406285072965

I don't know how dropped frame are being measured here so I can't really explain why they increase when using the correct refresh rate. I don't think going back to using the wrong refresh rate is an option though, especially because it causes other scheduling problems on some boards (eg. minnie).

The dropped frames is counted by webkitDroppedFrameCount in a video page.
Is there any way to resolve the dropped frame rate increase?

I'm not sure why the dropped frame rate increased to be honest. On cave for example https://crrev.com/c/1347444 changed the frame rate from 60hz (begin frame interval of 16666μs) to 60.0495hz (begin frame interval of 16652μs). 60.0495hz is the value coming from the display controller.

I took a look at WebMediaPlayer::DroppedFrameCount() but there is a lot of complexity there and it seems to come down to how the media stack schedules producing frames vs what is submitting the frames (either cc or the video in surface code) vs display scheduler drawing frames. So it could just be some bad interaction between the three(?) schedulers involved here.

How bad of a regression is this / how much time is warranted investigating it? I'm pretty confident https://crrev.com/c/1347444 is doing the right thing, plus Android CTS wasn't passing without it, so reverting probably isn't an option.