I'm creating a story to test the performance of CSS backdrop filters. When I run win-10-perf Pinpoint experiments with this story, I've noticed in the tracings that there tends to be a WaitForAck call in the GPU process (Graphics.Pipeline.DrawAndSwap), and this call can sometimes take really long, in the order of seconds.

My playground CL is at https://crrev.com/c/1340641. It's a simple Javascript animation. I tested it with Pinpoint in win-10-perf (3 runs):

Run #1: https://pinpoint-dot-chromeperf.appspot.com/job/132721b0140000
Run #2: https://pinpoint-dot-chromeperf.appspot.com/job/126151a7e40000
Run #3: https://pinpoint-dot-chromeperf.appspot.com/job/14014800140000

As an example, in the tracing of trial 7 of Run #1 (https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/blur_rotating_background_chromium@af912f6%20+%202b7e1c5_2018-11-16_10-27-22_2874.html), the WaitForAck near the beginning of the LetAnimationRun interaction lasts 2,537.278 ms. This duration is not consistent between trials (for example, in trial 2, it lasts 177.374 ms: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/blur_rotating_background_chromium@af912f6%20+%202b7e1c5_2018-11-16_10-26-58_59669.html). Also, the call is not always inside the LetAnimationRun interaction (see trial 3: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/blur_rotating_background_chromium@af912f6%20+%202b7e1c5_2018-11-16_10-26-56_74580.html).

I also ran a Pinpoint experiment on linux-perf bots for this CL and I didn't see this issue. The duration of the WaitForAck at the beginning is consistently around 80 ms.

Many more details:
------------------

1) I don't think this issue is specific to the new story. For example, I ran a Pinpoint on win-10-perf to measure rendering.desktop/keyframed_animations (https://pinpoint-dot-chromeperf.appspot.com/job/1584de60140000). Looking at trial 7 (https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/keyframed_animations_2018-11-13_14-47-58_72964.html), there is a WaitForAck near the beginning of the interaction that takes 3,202.913 ms.

2) I also feel that with the new story, I'm observing more TimeoutException errors in win-10-perf that seem unrelated to the story. For example, in a similar experiment (https://pinpoint-dot-chromeperf.appspot.com/job/1787fcf7e40000), trials 4 and 5 fail with this exception, and the logs mention "self.browser.tabs[0].WaitForDocumentReadyStateToBeComplete()". So, I wonder if this is related to the issue in this bug report.

3) The story in the playground CL uses action_runner.WaitForJavaScriptCondition() to detect the end of the animation. However, I have another CL where I do a pure CSS animation (no Javascript at all) and use action_runner.Wait(5): https://crrev.com/c/1324240. Not only am I observing the same behavior, but these long WaitForAcks can cause rendering metrics to not be collected. For example: see the tracing for trial 8 in https://pinpoint-dot-chromeperf.appspot.com/job/168fc8cbe40000 (tracing: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/blur_rotating_background_2018-11-12_09-40-04_30000.html). In that case, the WaitForAck never finished and all rendering metrics are (empty) which suggests that the animation didn't run. I didn't see this issue in a "Win 10 High-DPI Perf" bot run (https://pinpoint-dot-chromeperf.appspot.com/job/175079a7e40000). Also, I couldn't reproduce this issue in a local Win 10 machine.