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

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


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

linux-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/126a7666640000

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

Enable Viz Display Compositor on perf bots by fsamuel@chromium.org
https://chromium.googlesource.com/chromium/src/+/209e15b44e0c2c2d127b5c9a4416b996d663cc5e
4.85e+06 → 9.699e+06 (+4.85e+06)

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

I don't believe this is a real regression, but rather a memory tracking bug.

Looking at this graph:
https://chromeperf.appspot.com/report?sid=737c50b948668b60de4ae37fab77127bfca48a4af7b0e812999856e6895f34a9&rev=583572

Before trace: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/browse_media_youtube_2018-08-15_22-51-19_88054.html

Before: there's 12MB of cc memory in browser split between cc/tile_memory and cc/resource_memory. You'll see that both are linked to the gpu process textures (gpu/gl/textures).

After trace: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/browse_media_youtube_2018-08-16_01-35-51_82143.html

After: there's 12MB of cc in viz process and 5MB in browser process. The browser process has only cc/tile_memory which is linked to gl textures as before, but the viz process cc/resource_memory is not linked to gl textures. So that memory gets counted twice.

ericrk@ ^