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

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


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

Android Nexus6 WebView Perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14da6031640000

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

Add camera_to_webgl perf test to ToughWebglCases by kainino@chromium.org
https://chromium.googlesource.com/chromium/src/+/8ae85144bca45f0f0897d3deb3fc998e360e439b
0.711 → 0.8678 (+0.1568)

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

This is presumably because this case (aquarium) got re-recorded when I added the new case.

Aquarium has definitely seen some changes since the last time it was recorded. I'm surprised that those changes would have caused a regression, though. Not closing this bug yet since I'd like to know the answer before closing.

Took a look at performance and traces for the range 9d1acf6..a8abe78:
https://github.com/WebGLSamples/WebGLSamples.github.io/commits/a8abe78/aquarium
but didn't see anything.

Given there were major code changes (essentially, a replacement of the core code), I'm not going to further worry about this.

+oetuaho in case you're interested in this.

What's the test testing exactly - is it just normal single-view rendering of Aquarium? How many fish? Is the performance number JS main thread CPU use? I certainly didn't expect any performance regression from my changes so maybe putting a little bit of effort into trying to fix this is worthwhile.

Some things that changed when I reworked Aquarium:

1. Uniforms are set a bit differently. I wouldn't expect a performance loss from this, but it's possible. Unfortunately this is something that can't easily be changed.
2. Shaders are set on every frame. I already submitted a pull request to optimize this, since it was fairly simple to fix: https://github.com/WebGLSamples/WebGLSamples.github.io/pull/27

It should be exactly what loads when you go to https://webglsamples.org/aquarium/aquarium.html without any parameters.

However I'm not sure exactly what thread_raster_cpu_time_per_frame is measuring. I don't think it's the actual WebGL performance, but raster thread (compositing?):
https://cs.chromium.org/chromium/src/tools/perf/metrics/timeline.py?l=25&rcl=e830534349791e9fa99b52dd7b8e201d426d12bf

Thanks to a tip from vmpstr, I realized there are full traces from the pinpoint run. Examining these seems to indicate that everything paint/compositing related regressed slightly. It's not apparent to me why this could have happened, but I think that digging much deeper would not be worth the time.

Oh, also, the I believe the page was last captured in March:
https://chromium.googlesource.com/chromium/src.git/+/338cfa6d6375dd94f82e1efe7bb5d5c1e7a3fbc8
corresponding to the aquarium at this commit, presumably:
https://github.com/WebGLSamples/WebGLSamples.github.io/commit/9d1acf68c5c764d6ce6af25371fbbdee3d32ef6c

In the traces, specifically CompositorTileWorker1 since that's what seems to be measured by thread_raster_cpu_time_per_frame.

 Issue 880898  has been merged into this issue.