Culprit is https://chromium-review.googlesource.com/860266. Apparently fixing it once and for all has drawbacks.

I think there's something very weird going on here. Those graphs show that the memory was frequently spiking up to the value it's now settled on, suggesting that there was probably a race somewhere that this fixed.

My best guess is that somehow giving the toobar time to hide itself is freeing up GPU memory? If that's the case, we're probably also holding onto GPU memory for the whole page? Maybe we can somehow free all of it?

If anybody else wants to investigate, please do, otherwise I'll hopefully get to this soon-ish?

cc boliu who might have some knowledge here, or could at least point me to who would.

Is what I said in #c2 crazy? Are there GPU resources we could be freeing up while in WebVR presentation (when vsync is paused)?

+ericrk for general gpu memory knowledge

> Is what I said in #c2 crazy?

That looks like a real regression. The metric regressed is gpu:effective_size_avg, so it's an average over time, so unlikely to be some racy measurement thing. Does look awfully consistent, but this is "reported_by_chrome" value, so not too surprising.

Can't explain the spikes though. Maybe things are just racy sometimes.

> Are there GPU resources we could be freeing up while in WebVR presentation (when vsync is paused)?

I assume that's webgl going directly to its own surface and skipping all of chrome compositing? And that regular chrome compositing don't run anymore? In that case, yeah, a lot of things can be freed. The main signal to free memory is tab/activity becoming invisible, which I guess doesn't really work in this case.

Actually, tab hiding might not be too crazy, I'd have to look into it.

If that doesn't work, how difficult would it be to add some other signal to free up memory? I'm not sure what we would call this signal, because this is a very weird thing as far as the rest of Chrome is concerned, where the page is 'alive' and 'interactive', maybe even 'focused', but not visible.

A lot of other things are tied to visibility though, eg I don't think js is expecting a page that goes into vr becomes invisible, or that you are ok with the renderer running in a lower priority, things like that.

The renderer running in a lower priority would probably be pretty bad because we need the webVR page's javascript to run quickly, so I guess that's off the table.

Re #5 - 

I think comment #2 is actually pretty accurate. In this test, we take a single memory dump, so this is an average over 1 data point :P, so not really an average at all.

Looking at the before/after traces, it appears that we have one additional 8MB texture in the after trace. This is the same 8MB texture we see in the previous spikes.

Does look like a timing issue where something has or hasn't had a chance to happen at the point we take the dump.

> so this is an average over 1 data point :P

-_-

the art of trying to figure out how perf bot metrics are computed...

This regression was incidentally fixed by  issue 802090 .

Opened issue 803174 to track further work to reduce memory usage in WebVR.