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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgkpGWowoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg4ruBtQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgktK9vwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgkuLDqAoM


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

webrtc-win-large-tests

Casting a drive-by eye this... 

What caught my eye while idly browsing some perf graphs was the "WebRTC/webrtc-win-large-tests/webrtc_perf_tests / total_delay_incl_network / screenshare_slides_vp9_2sl" test. That went from 103 to 109 ms or so. Strangely not included in the "All graphs for this bug" link above, despite the alert in the graph linking to this bug...

Anyway, don't really see any obvious culprits in the WebRTC code. Thinking this is either something in libvpx or on the windows test machine itself. 

Looks like there was a libvpx roll around the time of the regression: https://codereview.chromium.org/2091483005
+marpan, anything in there that could explain this?

Don't see anything in that libvpx roll that would explain this change on windows only.