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

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


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

chromium-rel-mac11-pro

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12c596b2c40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/12c596b2c40000

VP8 color space fix by hubbe@google.com
https://chromium.googlesource.com/chromium/src/+/f9064b1d8b6e1c8335da4635fff2f750b3b3d0d5

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

hubbe: Looks like your VP8 color space fix regressed the performance benchmark. But, maybe this is acceptable and WAI, if an extra color space conversion step must now happen somewhere?

Note that the tab capture pipeline isn't color space aware at this point. Thus, I'm actually a bit confused as to how your change could have affected the "Capture Duration" metric at all. I'm thinking that this regression could indicate there are extra compositing steps for VP8 playback for all users due to an extra color space conversion step (i.e., is unrelated to tab capture)? If so, then the 10% regression is a bit more of a concern.

My change really shouldn't make a difference in speed. The color space conversion happens either way, just with slightly different multipliers.

However, I have another bug report that it causes major slowdowns on some ancient intel chipsets, I just don't know how.

The "all graphs for this bug" seems to indicate that this only happens on Mac, is that correct?

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1284ce42240000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16c2762c240000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14ada4bc240000

Currently these tests seems to die with a stacktrace which makes it a little more difficult to try things out.

#4 0x7fd2b05d27c2 service_manager::MergeManifestWithOverlay()
#5 0x7fd2b21b67a1 content::(anonymous namespace)::BuiltinManifestProvider::AddServiceManifest()
#6 0x7fd2b21b3d9a content::ServiceManagerContext::ServiceManagerContext()
#7 0x7fd2b1eca207 content::BrowserMainLoop::InitializeMojo()

Maybe I can check it out more tomorrow.

The crashes are known and should be fixed in ToT. They are related to the enabling of the new audio service (out-of-process).

Oh, and you can avoid them in the meantime with:

 --disable-features=AudioServiceAudioStreams,AudioServiceOutOfProcess

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/1284ce42240000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14ada4bc240000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/16c2762c240000

Ok, so I tried 3 more pinpoint jobs that all failed to reproduce the problem.
Maybe the problem doesn't actually exist?
Or maybe I'm using pinpoint wrong?

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12c3e81c240000

Could be that the system is misleading us, since the graphs all show a rather confident step-up signal. Though, that could have been caused by environmental changes or testing hardware changes or OS upgrades.

I've kicked-off one last wide-ranging bisect job. If it turns up negative, we can just WontFix.

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/12c3e81c240000

Still can't reproduce - closing.