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.
Starred by 19 users
Status: Fixed
Owner:
Closed: Feb 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Blocked on:
issue 64848

Blocking:
issue 73487

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Background tabs with webgl slow down browser due to missing flow control
Reported by sunandt@chromium.org, Dec 9 2010 Back to list
I loaded the following demos
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/san-angeles/index.html
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/shiny-teapot/index.html
http://webglsamples.googlecode.com/hg/aquarium/aquarium.html
http://webglsamples.googlecode.com/hg/field/field.html

GPU Process consumes ~250MB Memory on my Z600 dual processor with 16 cores

Issues:
1. Switching between tabs sharing GPU process is a lot slower than normal
2. The overall system performance degrades after trying to switch between tabs sharing GPU process
3. I have seen the application hang as well with just WebGL

The system starts responding again after I close the field WebGL demo.

This is with Google Chrome 9.0.597.15 (Official Build 68712) on Win7 x64

Let me know if more info is needed.
 
Labels: ReleaseBlock-Stable
I see this on mac as well.
I see high CPU usage by the GPU process and constant increase in memory usage (around to 250 MB) when I open all the above mentioned links and It has a bad affect on the overall system performance.

I tested this on a machine with NVIDIA GeForce 320M Graphics card on 10.6.4.


Comment 3 by hbridge@google.com, Dec 10 2010
Status: Assigned
Assigning to Vangelis.  This is the first time I've heard someone complain of this issue on Mac.  I've now tried to reproduce this myself on about 5 different machines and the only ones where I've seen the issue is with workstations that have the standard Quadro card.  Sunandt, Deepakg, do you have any idea what the regression range is?
Comment 4 by hbridge@google.com, Dec 10 2010
I was now able to reproduce this on my Mac with 10.6.4 and 9.0.597.15 dev on a Nvidia 330M GT.  The system slows to a crawl with the aquarium and field loaded in two tabs after you switch from one to the other.  Closing one tab returns the system to normal.  This looks like it might be a gpu multiplexing issue:

Webkit r73490 with WebGL enabled does not exhibit the same behavior: the system slows slightly, but only as you'd expect since the cpu is saturated.

I then ran 2 separate instances of Chrome (with a different userdatadir) each with one of the demos and the behavior was reasonable, similar to webkit's perf.
Comment 5 by hbridge@google.com, Dec 10 2010
Another datapoint: if you run the aquarium and field in the same browser but in different windows, the system does NOT slow down.  So it seems it may not be a scheduling/multiplexing issue, but that performance degrades when we draw an invisible tab.
Comment 6 by kbr@chromium.org, Dec 10 2010
That's interesting. The tests I did were with two copies of the aquarium in different windows, not different tabs. I'll take a look. CC'ing thakis as well. Might be a problem in the browser-side code.

Comment 7 by thakis@google.com, Dec 10 2010
Possible, but given that this happens on both windows and mac, and the browser code is pretty different…maybe not? :-)
Comment 8 by kbr@chromium.org, Dec 10 2010
Fair point. I was thinking about the differences on the Mac between two tabs per window vs. two windows.

Comment 9 by tha...@chromium.org, Dec 16 2010
Labels: -OS-Windows OS-All
Summary: Background tabs with webgl slow down browser due to missing flow control (was: NULL)
If I remember correctly, kbr analyzed this to be caused that we don't run the swap buffer callback for background tabs, which means that the flow control he put in ( issue 63539 ) doesn't happen.

Several solutions and workaround where discussed, but I had to leave early and missed the discussion.

(previous title: "Loading multiple WebGL demos affects system performance")
Comment 10 by kbr@chromium.org, Dec 16 2010
That's correct. The next planned change to address this general problem is to increase the minimum duration between firing of timers for backgrounded tabs.

Issue 67170 has been merged into this issue.
Comment 12 by nduca@chromium.org, Dec 16 2010
Comment 13 by kbr@chromium.org, Jan 6 2011
Labels: -Mstone-9 -ReleaseBlock-Stable Mstone-10
Comment 14 by kbr@chromium.org, Jan 22 2011
Blockedon: 64848
Labels: -Mstone-10 Mstone-11
jamesr's fix for  bug 64848  has improved the situation greatly for well written apps. Other work prevented doing this for M10; punting to M11.

Comment 15 by kbr@chromium.org, Feb 12 2011
The associated WebKit bug is https://bugs.webkit.org/show_bug.cgi?id=54312 . A patch is up for review.

Comment 16 by kbr@chromium.org, Feb 16 2011
https://bugs.webkit.org/show_bug.cgi?id=54312 has landed as http://trac.webkit.org/changeset/78620 . Waiting for the next WebKit roll to apply the Chromium side changes.

Project Member Comment 17 by bugdroid1@chromium.org, Feb 18 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=75404

------------------------------------------------------------------------
r75404 | kbr@google.com | Fri Feb 18 09:58:07 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/support/webkit_support.cc?r1=75404&r2=75403&pathrev=75404
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/support/webkit_support.h?r1=75404&r2=75403&pathrev=75404
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webpreferences.cc?r1=75404&r2=75403&pathrev=75404
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_glue.gypi?r1=75404&r2=75403&pathrev=75404
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=75404&r2=75403&pathrev=75404
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.h?r1=75404&r2=75403&pathrev=75404
 A http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_constants.h?r1=75404&r2=75403&pathrev=75404

Set the minimum timer interval on a per-page basis, and adjust it when
tabs are brought to the foreground and sent to the background.

This CL does not actually increase the background timer interval. That
will be done separately, so that it can easily be reverted without
removing all of the associated code.

BUG= 66078 
TEST=none (tested manually with minimal test case)

Review URL: http://codereview.chromium.org/6532012
------------------------------------------------------------------------
Project Member Comment 18 by bugdroid1@chromium.org, Feb 18 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=75430

------------------------------------------------------------------------
r75430 | kbr@google.com | Fri Feb 18 13:01:21 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_constants.h?r1=75430&r2=75429&pathrev=75430

Increase the minimum interval for timers on background tabs to reduce
their CPU consumption.

The new interval is 1000 ms, or once per second. We can easily adjust
this value up or down, but this seems like a reasonable value to judge
the compatibility impact of this change.

BUG= 66078 
TEST=none (tested manually with minimal test case)

Review URL: http://codereview.chromium.org/6546021
------------------------------------------------------------------------
Comment 19 by kbr@chromium.org, Feb 18 2011
Status: Fixed
With the above two CLs, the minimum timer interval for background tabs has been fairly drastically increased to 1 second. This means that even if the application uses setTimeout or setInterval with a delay of 0 ms, the timer won't go off more often than once per second if the tab is in the background.

There might be compatibility ramifications of this change, but the thinking is that this is the right thing to do in order to decrease CPU consumption and increase battery life on mobile devices.

I'm closing this as fixed. Please file a new bug for any issues with the background tab minimum timer interval.

Project Member Comment 20 by bugdroid1@chromium.org, Feb 19 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=75490

------------------------------------------------------------------------
r75490 | sadrul@chromium.org | Fri Feb 18 23:36:28 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_constants.h?r1=75490&r2=75489&pathrev=75490

Revert 75430 because it's causing failures in dom_checker_tests.
: Increase the minimum interval for timers on background tabs to reduce
their CPU consumption.

The new interval is 1000 ms, or once per second. We can easily adjust
this value up or down, but this seems like a reasonable value to judge
the compatibility impact of this change.

BUG= 66078 
TEST=none (tested manually with minimal test case)

Review URL: http://codereview.chromium.org/6546021

TBR=kbr@google.com
Review URL: http://codereview.chromium.org/6538073
------------------------------------------------------------------------
FYI:
r75430 also broke animation of Browser Action icon on toolbar.
(Especially rotation in "Google Mail Checker" extension)
After r75490, it works as before.
Comment 22 by thakis@google.com, Feb 21 2011
Satoshi: Can you file a new bug for that and mention the bug # here, please?
Filed comment #21 as  Issue 73726  for tracking purpose.
Could you please take a look?
Comment 24 by kbr@chromium.org, Feb 22 2011
Status: Assigned
Reopening because http://codereview.chromium.org/6546021 was rolled out. Going to investigate the dom_checker_tests failure and  Issue 73726 .

Comment 25 by kbr@chromium.org, Feb 22 2011
@sunandt: I can not reproduce the dom_checker_tests timeouts with a local Debug build of ui_tests on Mac OS X including http://codereview.chromium.org/6546021 . I ran both:

src/xcodebuild/Debug/ui_tests --gtest_filter=DomCheckerTest.\*

as well as a full ui_tests run. There were a few failures but none in the DOM checker tests, and I assume the failures are unrelated to my change.

How can I reproduce these failures locally to debug?

@kbr: Google Chrome 11.0.680.0 (Official Build 75562) seems to work a lot better when compared to 9.0 build. Even the memory consumption is less(~180MB). Except for a little lag, we are doing fine while shifting tabs.

I can't repro the Google Mail Checker extension issue as well.


Comment 27 by kbr@chromium.org, Feb 22 2011
@sunandt: I've been able to reproduce the mail checker extension issue ( issue 73726 ), which was definitely caused by my changes. The question is specifically how to run the dom_checker_tests.

iirc the dom_checker_tests were failing in release only, not debug.
@kbr: I don't know how to repro those test failures locally.
Project Member Comment 30 by bugdroid1@chromium.org, Feb 23 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=75700

------------------------------------------------------------------------
r75700 | kbr@chromium.org | Tue Feb 22 18:45:51 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webpreferences.cc?r1=75700&r2=75699&pathrev=75700
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=75700&r2=75699&pathrev=75700

Initialize the minimum timer interval upon RenderView construction,
not during WebPreferences application, and base the interval on the
initial hidden state of the view.

This fixes a bug introduced late in the development of the minimum
timer interval for background tabs, and also will fix
http://code.google.com/p/chromium/issues/detail?id=73726 once the
minimum timer interval is increased again.

BUG= 66078 
TEST=manual tests

Review URL: http://codereview.chromium.org/6546080
------------------------------------------------------------------------
Comment 31 by kbr@chromium.org, Feb 24 2011
 Issue 73726  has been merged into this issue.
Project Member Comment 32 by bugdroid1@chromium.org, Feb 24 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=75973

------------------------------------------------------------------------
r75973 | kbr@google.com | Thu Feb 24 14:23:56 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_constants.h?r1=75973&r2=75972&pathrev=75973

Increased the minimum timer interval for background tabs to 1000
milliseconds again.

With a recent Chromium side bug fix and
http://trac.webkit.org/changeset/79455 integrated, we're ready to try
increasing this interval again.

BUG= 66078 
TEST=none (layout tests, manual tests, trybots)

Review URL: http://codereview.chromium.org/6577021
------------------------------------------------------------------------
Comment 33 by kbr@chromium.org, Feb 25 2011
Status: Fixed
The increase to the minimum interval for timers on background tabs has been committed again. It looks like it won't be rolled out due to test failures, though I can imagine that there may be compatibility issues that cause it to be adjusted.

Closing as fixed again.

Comment 34 by kbr@chromium.org, Feb 25 2011
 Issue 73487  has been merged into this issue.
Project Member Comment 35 by bugdroid1@chromium.org, Oct 13 2012
Blockedon: -chromium:64848 chromium:64848
Blocking: -chromium:73487 chromium:73487
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 36 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Feature-GPU -Mstone-11 Cr-Internals-GPU Cr-Internals M-11
Project Member Comment 37 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment