All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=897164

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


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

chromium-webrtc-rel-7
chromium-webrtc-rel-win10

Range isn't that large but nothing pops up as culprit. Will dig into each CL.
https://chromium.googlesource.com/chromium/src/+log/6057fc833dff221a6f84971d060f6293bd9263ab..ab5288ecaaaeb91f71b1ff43b8e5aa15d3fc1cb3

I think the range is off by one and culprit is this CL:
https://chromium.googlesource.com/chromium/src/+/892404731a96d57c5162ae52a0fe978ecff80fbf
https://chromeperf.appspot.com/group_report?rev=600836

lethalantidote@ can you explain how using surface layer affects latency? These tests measure the how quickly frames are picked up from decoder to screen for real-time apps that are sensitive to latency.

That CL now turns off Surfaces in trunk, so what we are seeing here is a regression that surfaces was covering up.