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

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


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

mac-10_13_laptop_high_end-perf

rendering.desktop - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/17d332ad640000

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

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

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13ed6179640000

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

Restrict FlushForDriverCrashWorkaround to non-WebGL contexts. by kbr@chromium.org
https://chromium.googlesource.com/chromium/src/+/4dc2e915fde1b77566d7ccd721e2b990a7f976f3
0.249 → 0.4142 (+0.1652)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

queueing_durations for aquarium.20k went from ~0.1 to ~0.4 ms. This seems to be this metric:
https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/web_perf/metrics/smoothness.py?type=cs&q=queueing_durations&sq=package:chromium&g=0&l=41

"The queueing delay between compositor & main threads"

This increase seems reasonable because we're likely submitting more work each batch.

I don't think this case is worth making any changes over – especially adding complex heuristics where deciding when to flush. Closing as WontFix and linking to related bug.