New issue
Advanced search Search tips

Issue 844653 link

Starred by 3 users

Issue metadata

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

Blocking:
issue 837646



Sign in to add a comment

reduce the times of glDrawElement in our render loop

Project Member Reported by bshe@chromium.org, May 18 2018

Issue description

The number of glDrawElements can largely impact performance. On mobile VR applications the general consensus is that more than 50-100 draw calls per frame will limit your ability to hit a 60Hz refresh rate. [refer: https://google.github.io/gapid/tutorials/optimize]
This might not be a problem for us at the moment, but as we add more UiElement which had glDrawElement. We might bite by this. This is to track reduce the number of glDrawElements in our render loop.

One possibility is here:
https://cs.chromium.org/chromium/src/chrome/browser/vr/renderers/textured_quad_renderer.cc?rcl=4a6e4e7bab49b8002e2c7c1d1611af4239aae127&l=257

We could probably do the same for gradient rect too.
 
One thing to note is that instancing requires that textures don't change. Everything (corners, clips, etc.) else is probably manageable through array attributes. Because of that, if any, we should start with gradient rects.
In order to take full advantage of the change, we need to first get sorting of elements going. I have an experimental CL on this crrev.com/c/1069591 which didn't have any noticeable performance gain. But if we can draw all our gradients at once, we probably will see some improvement, as we will be saving GPU cycles.
Labels: -Type-Bug Type-Task

Comment 4 by ddorwin@chromium.org, Jan 18 (4 days ago)

Labels: OS-Android

Sign in to add a comment