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

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


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

android-nexus5X

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12e1e850a40000

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

Turn on OOP Raster on android bots by enne@chromium.org
https://chromium.googlesource.com/chromium/src/+/d82c4fabc5cc6cbe6b475186ed9fa0216980e533
662.6 → 947.3 (+284.7)

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

Oops, this is time to first paint. I was duping all memory regressions into a single bug.

This (background:search:google) appears to be the only time to first paint regression in rendering.mobile.  All the other filter story sets did not regress and this is a single page.

Additionally, PageLoad.Experimental.PaintTiming.NavigationToFirstMeaningfulPaint does not seem to regress (mild but not significant progression) with the DefaultEnableOopRasterization finch trial turned on.  So, I do not think that this is indicative of widespread problems across more pages than this.

Looking into this more directly to see if there's some opportunity for improvement:  Some of this regression is due to parallelization (https://docs.google.com/document/d/1aAmFiBlrv2wV8QE1ySdHoNi6sPspWyrJwnolk8QnfNU/edit#heading=h.ygv2hhahttvm) but not all of it.

The rest of the regression looks like it is due to create the CCPR atlas (RenderAtlasOp (CCPR) in the trace).  That makes this particular test case look like it is a dupe of issue 860021.  Switching from es3 to es2 causes this regression to go away locally on an n5x.