New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 868717 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

A zero-to-nonzero to 19.7% regression in browser_tests at 578747:578897

Project Member Reported by niklase@chromium.org, Jul 29

Issue description

Tons of latency changes, couldn't see an obvious cause.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=868717

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=e84a219536f522ffdcaff157ce9c3ca9a059cc81ce6dd56f515554b4cde2d2ae


Bot(s) for this bug's original alert(s):

chromium-webrtc-rel-7
Cc: fsam...@chromium.org emir...@chromium.org
Components: Blink>WebRTC
Owner: uwyiming@chromium.org
578747 - 578863 is the most likely interval for regression although there is 3 different ones reported. Unfortunately there are 117 CLs in that range, not easy to point out the culprit.

This is Win7 only regression. I checked if there was any change in infra on this bot, but nothing came up. Looking at the individual breakdown below, it looks like "Render Algorithm Latency" went down but everything else went up:
https://chromeperf.appspot.com/report?sid=fb64fa9d58947b6141af4648c671febce9d5b24042c4204c38fd677f9f1094aa&start_rev=577187&end_rev=578955
"Render Algorithm Latency" corresponds to the time between "WebMediaPlayerMSCompositor::EnqueueFrame" and "WebMediaPlayerMSCompositor::SetCurrentFrame" calls that is actually spent in VideoRendererAlgorithm. This is decided by presentation deadline given in https://cs.chromium.org/chromium/src/cc/layers/video_frame_provider.h?type=cs&sq=package:chromium&g=0&l=62. 
Render algorithm isn't the culprit here because we have another test where render algorithm is disabled all together(representing playout-delay=0 use case). There, we see that "Compositor Picking Frame Latency" went up, which corresponds to the time between "WebMediaPlayerMSCompositor::SetCurrentFrame" and "WebMediaPlayerMSCompositor::GetCurrentFrame" calls. Since "WebMediaPlayerMSCompositor::GetCurrentFrame" is driven by the vsync interval and presentation update as well, that points to a change in the decided interval.
https://chromeperf.appspot.com/report?sid=7c0a38cb7bd46f88cf5dcc4ac385ad2d40d761bfb101ed742432715e9f9d02c4

From the list this one seems to be most likely suspect affecting vsync interval. uwyiming@ or fsamuel@ can you PTAL if this would be related:
https://chromium.googlesource.com/chromium/src/+/f0d7951f253c73c2678c83af541481bb34276a40
Reverted responsible change in https://chromium-review.googlesource.com/c/chromium/src/+/1153594. If the fix is effective, we should resolve this bug as a dupe of   bug 866981  .
The suspected range includes https://chromium-review.googlesource.com/c/chromium/src/+/1153594. Do you mean you are going to reverse that CL?
Friendly ping.

Sign in to add a comment