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

Issue 831618 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Task
Proj-XR
Proj-XR-VR

Blocking:
issue 837646



Sign in to add a comment

VR UI performance: Measure performance improvement of not overdrawing content

Project Member Reported by cjgrant@chromium.org, Apr 11 2018

Issue description

Our current UI draws the background, then (possibly) the reposition frame, then content.  This overdraws over the entire content region, which is expensive.

The UI currently relies on having the GL depth buffer disabled.  We shoudl investigate whether select use of the buffer could help trim this time substantially.  We'd continue to avoid the depth buffer for all other elements.

 

Comment 1 by tiborg@chromium.org, Apr 13 2018

Labels: -M-67 -Hotlist-VRB-MVP M-68 Hotlist-VRB-MVP-Next
Removing MVP since current perf is fine for launching. Chris, please re-add MVP if you disagree.
I completely agree.  Thanks Tibor!
Blocking: 837646
Labels: -Hotlist-VRB-MVP-Next
Labels: -Type-Bug -M-68 Type-Task
Owner: ----
Status: Available (was: Assigned)
Just a thought: What if we made the background renderer aware of where the holes for the quad layers need to be and it handled drawing transparent there? Would that be expensive?
If we were using the depth buffer, we could stuff the holes in there, but that seems to add to the specific problem we're trying to solve (we'd be drawing quads, then the background, then the quad layers).

In the background shader, doing a "for each of these regions, don't draw if we're behind one" feels like it'd be very expensive.  Also, I don't know how we'd handle that since the holes would project back onto the spherical background mesh, creating odd shapes that would have to be computed at some point and per-frame.

If we're targeting only content, I think there's a simpler (but still hacky) approach we haven't taken yet.  Based on where content is located, we can figure out which background triangles aren't visible, and skip drawing them.  This would be easier if the triangles behind content were at the end of the vector, and we were just choosing when to stop drawing.  This gets worse when considering fullscreen and content repositioning though, and it scares me because it adds quite a bit of complexity in exchange for only saving overdraw on part of one big quad.


Comment 9 by samdrazin@chromium.org, Today (16 hours ago)

Cc: cassew@chromium.org
I wonder if metrics could help us track the impact / potential gains of addressing this.

Sign in to add a comment