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

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


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

chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
win-high-dpi

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16cc05c3440000

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

GLES1: Revise entry points by lfy@google.com
https://chromium.googlesource.com/angle/angle/+/a0648780be21a9ee3008a9b518d4d5a5d940ec7f

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

Assigning to reviewer jmadill: looks like lfy can't own chromium issues, but the CL above seems to have regressed skia desktop memory by 4MiB. Can you help triage?

I can't help triage, as I'm out of the office for the next week.

Frank can you help figure this out? It seems hard to understand immediately why a refactor like in your CL would cause a 4mb regression in memory usage.

sullivan@ when you say skia desktop memory, where does the "skia" part come into play?

I have little idea either, since the only thing it did was move a lot of entry points from libGLESv1_CM back to libGLESv2, which might inflate code size. But then libGLESv2.dll should contain the same code as libGLESv1_CM, right? We could also trace back to when we originally moved the GLES1-common-with-GLES2 entrypoints out of libGLESv2 and into libGLESv1_CM, and compare the trivial page memory usage there.

Let's try looking up the memory usage for the trivial page around https://chromium.googlesource.com/angle/angle/+/2aaa7b4e1040d90d5ef2dbd2ba53761d88528b79

re #5: The metric that regressed was memory:chrome:all_processes:reported_by_chrome:skia:effective_size_avg. You can see a guide to the naming here: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md#understanding-memory-metrics

You can see traces with memory dumps in the pinpoint link by clicking on the data point in the chart. Here they are
before the patch: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/TrivialCanvasPageSharedPageState_2018-03-25_15-40-29_36152.html
after: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/TrivialCanvasPageSharedPageState_2018-03-25_17-37-59_14260.html

I attached a screenshot of the two dumps, there seems to be an extra resource in skia gpu_resources.

Deleted: before-after-memory.png 146 KB

	before-after-memory.png 146 KB View Download

Is there anyone (maybe from the Skia team who knows the metrics well) who can help us triage this issue and understand what gpu resources might have been changed?

Anyone from Skia able to assist here?

Getting Skia GPU team on for a look...

I've never seen this type of metrics report before. There isn't really much information in it to use to diagnose.

+Justin re canvas 2d. Is it possible that some timing difference is causing the memory report to sometimes be generated when there are 2 canvas backing stores and sometimes when there is 1? I ask because resource_5 and resource_7 appear to be the same size and the graph appears to jump between 9MB and 13MB somewhat noisily not just at Jamie's change.

Could use some help with this.

Looking at this graph (and expanding the displayed changelist range a bit):

https://chromeperf.appspot.com/group_report?bug_id=825591

I conclude that the metric is noisy and nothing happened at your CL.

OK, thanks Brian.