New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 728885 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
inactive
Closed: Jun 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocking:
issue 725303
issue 725306



Sign in to add a comment

GLRenderer::DidChangeVisibility false never called on Android

Project Member Reported by aelias@chromium.org, Jun 2 2017

Issue description

This visibility notification path was unhooked at some point during the refactoring to split into layer/surfaces compositor in the last year or two.  It was rehooked but only for Aura in https://codereview.chromium.org/2238693002, leaving Android with visibility permanently true on the root display compositor.

From a quick memory comparison on Nexus 6P, the memory released by this path on Android is within the noise at moment.  But it's definitely expected to be hooked up to release whatever it's holding.

Foreground nytimes: 
     95,593K: org.chromium.chrome (pid 12479 / activities)
     88,260K: org.chromium.chrome:privileged_process0 (pid 12567)

Background nytimes with fix:
     64,822K: org.chromium.chrome (pid 12932 / activities)
     37,687K: org.chromium.chrome:privileged_process0 (pid 13025)
(again)
     70,994K: org.chromium.chrome (pid 11465 / activities)
     38,451K: org.chromium.chrome:privileged_process0 (pid 11554)

Background nytimes without fix:
     63,843K: org.chromium.chrome (pid 12479 / activities)
     38,577K: org.chromium.chrome:privileged_process0 (pid 12567)
 
Status: WontFix (was: Assigned)
Bo pointed out the display compositor is destroyed instead on background which does a superset of SetVisibility(false), so I'll close this.  Just need to continue being careful that visibility side effects happen both on destruction and visibility change...

Sign in to add a comment