My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 151087: Opening a lot of browser windows makes background go white
4 people starred this issue and may be notified of changes. Back to list
 
Reported by alex.kus...@gmail.com, Sep 20, 2012
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
Sep 20, 2012
#1 rby...@chromium.org
(No comment was entered for this change.)
Labels: -Area-UI
Sep 21, 2012
#2 Kusc...@chromium.org
Stefan or Sky can you look into this?
Status: Assigned
Owner: skuhne@chromium.org
Cc: sky@chromium.org
Labels: -Hotlist-Link Mstone-23 Feature-Ash-WM ReleaseBlock-Stable
Sep 21, 2012
#3 piman@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).
Cc: ccameron@chromium.org danakj@chromium.org
Sep 21, 2012
#4 danakj@chromium.org
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.
Sep 21, 2012
#5 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?
Owner: sky@chromium.org
Sep 21, 2012
#6 ccameron@chromium.org
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.
Sep 21, 2012
#7 sky@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.
Owner: saintlou@chromium.org
Cc: piman@chromium.org
Sep 21, 2012
#8 saintlou@chromium.org
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).
Status: Available
Owner: ---
Labels: -Pri-2 -Restrict-View-Google -BugBash -Mstone-23 -ReleaseBlock-Stable Pri-1 Mstone-24
Sep 21, 2012
#9 ccameron@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.
Cc: davemo...@chromium.org
Sep 21, 2012
#10 piman@chromium.org
@#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.
Sep 21, 2012
#11 ccameron@chromium.org
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.
Oct 2, 2012
#12 saintlou@chromium.org
 ccameron please try and let us know. Thanks!!!
Status: Assigned
Owner: ccameron@chromium.org
Oct 2, 2012
#13 piman@chromium.org
 Issue 153657  has been merged into this issue.
Cc: skuhne@chromium.org Kusc...@chromium.org rby...@chromium.org saintlou@chromium.org zelidrag@chromium.org derat@chromium.org jamescook@chromium.org
Oct 2, 2012
#14 piman@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-24 Mstone-23 ReleaseBlock-Stable
Oct 3, 2012
#15 ccameron@chromium.org
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)?
Oct 3, 2012
#16 piman@chromium.org
I can help you
Oct 3, 2012
#17 ccameron@chromium.org
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.
Oct 3, 2012
#18 danakj@chromium.org
We paint in front-to-back order for things of equal priority. The background is the first thing to lost its texture memory.
Oct 3, 2012
#19 piman@chromium.org
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.
Oct 4, 2012
#20 Kusc...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-23 Mstone-24
Oct 20, 2012
#21 Kusc...@chromium.org
piman is there something actionable here / should we punt / close out?
Owner: piman@chromium.org
Oct 20, 2012
#22 piman@chromium.org
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.
Status: WontFix
Oct 20, 2012
#23 derat@chromium.org
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.
Mar 10, 2013
#24 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-24 -Feature-Ash-WM Cr-UI-Shell-WindowManager M-24
Sign in to add a comment

Powered by Google Project Hosting