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

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


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

chromium-rel-mac12

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

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

Ensure that an OOPIF renderer knows its size before layout. by lfg@chromium.org
https://chromium.googlesource.com/chromium/src/+/e5d27a36230aea4b3664f8b5345b09bb0690a3ff

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

This is a memory regression reported by cc memory. It's hard to know exactly where it's coming from, but it's a difference in texture sizes reported by cc (see attached screenshot).

Deleted: memory.png 26.6 KB

	memory.png 26.6 KB View Download

Given that this is a small change, I don't feel it's worth the time to investigate the changes. My patch does change the timing of when rendering starts, and it could lead to small differences in when these textures get allocated.

Given that this is a necessary bugfix, I'll archive this issue. Please reopen if you think this is worth digging further.