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

Issue 883405 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Sep 28
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression
Proj-VR
Proj-XR
Proj-XR-VR



Sign in to add a comment

1.8%-1643.5% regression in xr.browsing.wpr.static at 589617:589704

Project Member Reported by bsheedy@google.com, Sep 12

Issue description

Bisect points to https://chromium-review.googlesource.com/1205202 as the culprit. The absolute increase is at most ~150 KB though, so it's probably safe to just eat the increase.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=883405

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=912617a87e28b6ac6c65eca55d28fa142abbebc82f53660912a17e97a598b1de


Bot(s) for this bug's original alert(s):

pixel_2_xl
pixel_xl
Components: Internals>XR>VR
Labels: VR-Perf
Looks like there are actually a couple of ~30 MB regressions
ya just saw it. looking at it.
Cc: ericrk@chromium.org
Status: Fixed (was: Assigned)
I looked at the failing tests.
The increase in memory is not a bug in this case.

The code without my CL was buggy.
Gpu services were backgrounded and transfer cache was cleaned whenever the CompositorImpl/SurfaceView was destroyed or not visible. This was incorrect behavior.

My CL fixed it to only background the gpu services and clean cache when the whole app/browser is minimised/backgrounded.

Since the trace is recorded before the browser is closed/backgrounded, my CL shows more memory occupied due to transfer cache not being cleaned up until the browser gets backgrounded.


Sign in to add a comment