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

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


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

chromium-rel-mac11-pro

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15e205be440000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11f2505e440000

Kicking off a few more bisects.

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

InterprocessFramePool rewritten to also work with ChromeOS sandbox. by miu@chromium.org
https://chromium.googlesource.com/chromium/src/+/aa3b9baaee9e212ae25390143d51a46920a2e380

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

No regression because the 0.4 ms shifted from one "stage" in the pipeline to another: We see a 0.4 ms drop in "send_to_renderer" at the same time the 0.4 ms increase in "encode" happens. Also, "total_latency," which encompasses all stages has remained unchanged.

In fact, it was a performance improvement because another stage, "capture_duration," saw a 0.75 ms improvement! So, the new buffer pool is more performant overall.

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

InterprocessFramePool rewritten to also work with ChromeOS sandbox. by miu@chromium.org
https://chromium.googlesource.com/chromium/src/+/aa3b9baaee9e212ae25390143d51a46920a2e380

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

I meant it last time. :)