Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 151087 Opening a lot of browser windows makes background go white
Starred by 4 users Reported by alex.kus...@gmail.com, Sep 20 2012 Back to list
Status: WontFix
Owner:
Closed: Oct 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment
See screenshot. I opened a lot of browser windows using Ctrl + N a lot.
 
Screenshot 2012-09-20 at 7.18.00 PM.png
533 KB View Download
Comment 1 by rbyers@chromium.org, Sep 20 2012
Labels: -Area-UI
Cc: sky@chromium.org
Labels: -Hotlist-Link Mstone-23 Feature-Ash-WM ReleaseBlock-Stable
Owner: skuhne@chromium.org
Status: Assigned
Stefan or Sky can you look into this?
Comment 3 by piman@chromium.org, Sep 21 2012
Cc: ccameron@chromium.org danakj@chromium.org
Most likely, we run out of GPU memory, so something has to go.
Are all windows in a "visible" state or minimized?

I wonder if we're doing something that makes culling not work (since paint culling is supposed to help us with memory).
Comment 4 by danakj@chromium.org, Sep 21 2012
Without ubercomp the renderer contents can't be culled and take up gpu memory.

We could stop trying to display windows beyond the first 5 or 10 MRU or something to compensate.
Comment 5 by sky@chromium.org, Sep 21 2012
Owner: sky@chromium.org
If we want the UI to deal with this, we need a way to know when we're close to running out of video memory. Do we have such a thing?
We never let the memory budget for any compositor go below a certain threshold (64MB is the default that things came in with).  We can make this value be higher for Chrome OS.  Ideally the UI should have a way to communicate to the management scheme that it is extra important.
Comment 7 by sky@chromium.org, Sep 21 2012
Cc: piman@chromium.org
Owner: saintlou@chromium.org
I think there are things we can do here, but only if the UI knows we're running low on memory (or can calculate that we're low on memory). I'm kicking this back to Emmanuel to find someone to plumb through something like that, at which point the UI could try and free up some video memory.
Labels: -Pri-2 -Restrict-View-Google -BugBash -Mstone-23 -ReleaseBlock-Stable Pri-1 Mstone-24
Owner: ----
Status: Available
This is nothing new, we had a similar issue filed against 19 and we never solved it. I like sky@ suggestion at #7 and we should do something in M24 (and by that same token we should also warn about low disk space).
Cc: davemoore@chromium.org
Adding David to CC -- David, does this look like the issue you were seeing?  Would exempting the window manager from having its memory managed fix this issue?  

If so, we're trying to get that into M23.
Comment 10 by piman@chromium.org, Sep 21 2012
@#4: "running out of GPU memory" I meant that in the context of the compositor memory allocation, which doesn't count the renderer textures (they're allocated externally). 

We also release front and back surfaces now, for background tabs, so (hopefully) they shouldn't be counted towards the memory usage.

In the past, thanks to your culling changes, we were able to open many windows without trouble. Culling made it that windows in the background could drop their UI tiles because they were occluded by front windows, allowing us to work with many windows in a small working set. I just want to make sure we haven't regressed there for some reason.

That being said, it's also possible that the minimal allocation (32MB), that we'll get under high memory pressure, is small for UI on Arrow, and we should raise it.
Raising the limit is a small change and easy to test -- content/common/gpu/gpu_memory_manager.h:114 GetMinimumTabAllocation.  Change this to, say, 128 or 256 on Chrome OS to see if it makes a difference.
Owner: ccameron@chromium.org
Status: Assigned
 ccameron please try and let us know. Thanks!!!
Cc: skuhne@chromium.org rbyers@chromium.org jamescook@chromium.org derat@chromium.org zelidrag@chromium.org saintlou@chromium.org kuscher@chromium.org
 Issue 153657  has been merged into this issue.
Labels: -Mstone-24 Mstone-23 ReleaseBlock-Stable
The change is really simple, but I'll to try it out on an Arrow device to give it a try -- does anyone in MTV have a system that I can run over and check out (something with a working build that I can modify there)?
I can help you
I ran the experiment of doubling the minimum to 128, and the background-white-out still happened, but with many more windows before hitting it.  I'm surprised that the background-white-out would happen at all -- does the compositor which draws the background need to draw more stuff for each window that is created?

Also of note is that David's fix for issue 146448 will alleviate this issue somewhat on its own.  We'll hold off on doubling the limit until we can observe the effect of the fix for issue 146448.
We paint in front-to-back order for things of equal priority. The background is the first thing to lost its texture memory.
I don't think we have perfect culling, so all windows will always be allocating at least a little bit.
I tried again and the number of windows at which the issues started appearing was close to 40 (all on the NTP). The OOM killer started killing tabs way before that.
Labels: -Mstone-23 Mstone-24
Owner: piman@chromium.org
piman is there something actionable here / should we punt / close out?
Comment 22 by piman@chromium.org, Oct 20 2012
Status: WontFix
As we raised the memory limits, I don't think there's an immediate issue here - we'll have OOM problems (killing tabs) before we run into GPU memory limits for the UI.
If anything we may want to add some limits at the UI level - prevent the user from opening more than, say, 20 windows, because they'll have a degraded experience after that. Feel free to file  a separate bug for that.
Comment 23 by derat@chromium.org, Oct 20 2012
Fun fact: We were discussing limiting the maximum number of windows that can be opened way back in http://crosbug.com/1471.  I think that there was a perhaps-even-older "system crashes when I hold Ctrl-N for a while" bug, but I can't find it now.
Project Member Comment 24 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Mstone-24 -Feature-Ash-WM Cr-UI-Shell-WindowManager M-24
Sign in to add a comment