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

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


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

chromium-rel-mac11-air

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

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/11c04644c40000

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

 Issue 829841  has been merged into this issue.

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

Reland "Enable WebRtcUseGpuMemoryBufferVideoFrame feature by default" by emircan@chromium.org
https://chromium.googlesource.com/chromium/src/+/a1b68fd522584c38840cc4adc3396812e59f6809

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

miu@ can you take a look at this to see if it is expected? After this CL, we upload frame content to GMBs in WebMediaPlayerMS. With that, we replace slow VideoResourceUpdater::CreateForSoftwarePlanes() calls. TabCapturePerformance_comp_gpu_webrtc doesn't seem to be affected, but TabCapturePerformance_comp_gpu tests are. "CaptureLatency" shows the regression clearly. From my understanding, this captures the time between async trace calls for "Capture". Why do you think GMB backed video buffers will cause a longer capture time? 
https://chromeperf.appspot.com/report?sid=b4ea0ce7c39387fbd05f361b5dde2cb465eba21a5f6087b72c498d6228022ff0&start_rev=526440&end_rev=553690

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1047caa3c40000

I started the above for a regression on mac-pro bot, but it doesn't seem like the same range. You can ignore it.

I tried reproducing this on my local 16MBP by enabling/disabling GMB usage in this test, but unfortunately I cannot reproduce the regression. It looks like it only happens on Mac11-Air bot either way. This perf bot is running a VM. I am thinking if this bot is actually capturing the HW performance difference. From what I understand, capture goes through FrameSinkVideoCapturerImpl and GLRendererCopier. At that point it is reading back I420 from a composited RGB texture. It shouldn't make any difference if we are using GMB or not at that point as we have a composited RGB texture. I cant tell why reading that would take longer. 
https://build.chromium.org/deprecated/chromium.perf/buildslaves/vm68-m1

Adding hubbe@ for advice as well as miu@ is OOO.

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

Enable skcms in Skia by brianosman@google.com
https://chromium.googlesource.com/chromium/src/+/a3796c2471b11c81c8b532d66388c1b5ea708c07

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

I tried to repro locally on an Early-2015 Macbook Air, but there is no regression between GMB enabled/disabled. Waiting for comments before marking this as WontFix.

Thanks for taking a look. Since there isn't an obvious regression, it could be some change to the testing environment/infrastructure (or an OS update?). In any case, the current performance is in-line with the trailing 12-month period; and I'll probably be spending time in Q3 on optimizing tab capture performance throughout the end-to-end pipeline.