Example graphs:

Skia https://chromeperf.appspot.com/report?sid=d527e575ec1422f1e2466dccc61754230edc665f7986db587429822f54fa9528&rev=511459

GPU: https://chromeperf.appspot.com/report?sid=3c7a0363f2179e496ee603ce734ad466a41f3c6ec6c5d3060dea7cc7596f4739&rev=511459

FYI, this also seems to have caused an FPS regression which wasn't caught by alerts due to some issues with the perf tests that have since been resolved. On average, it's a ~2 FPS drop, but on some pages, it's as much as ~5 FPS.

Ok, I will revert.

I'm going to try and investigate the root cause and fix this before resorting to a full revert. Bumping up the priority because of the performance impact.

I believe Klaus took a look at this and it looks like it's WAI. Is that true?

I didn't look at memory usage. As far as performance is concerned, the slowdown happens during the 5 seconds where the WebVR entry toast is displayed (kExclusiveScreenToastViewportAware), and this is a side effect of the extra rendering cost due to the active overlay layer used to display the toast.

Assuming that we want and need the overlay, this would be WAI, but it's a separate question if it's worth the performance cost. It would be unfortunate if it causes a bad first impression for VR experiences that may be tuned for steady-state performance, but I assume it will often show at the same time as a splash screen where it may not matter.

I'll go ahead and close this since the performance hit is expected, and not including the offending toast isn't an option.

This is related to https://crrev.com/c/701774, right?

Can you be more specific about the impact? Does this regression affect the first 5 seconds of all WebVR presentations or only seconds 3-5 when failing to produce frames for 2+ seconds?

On the test side:
If the sample is not producing frames, how are we determining the FPS regression? Isn't it 0 for the first 5 seconds?
Is this changing the meaning of these tests and/or causing us to test something different than intended?

The sample is producing frames. Nothing has changed in terms of the meaning of the tests. I'm not exactly sure why this change would cause a performance regression due to the WebVR presentation toast, as that seems to have been in before the offending CL, but Klaus can probably give an explanation.

As far as I can tell, the performance regression matches the time that the toast is showing, which I think is based on a 5-second timer that starts when the first frame was produced. So the first 5 seconds of all WebVR presentations would be affected by this.