Poor performance on Pixel XL & Daydream

Description of the problem

Trying any simple webvr example (eg: https://developers.google.com/vr/tools/perfhud) on a Pixel XL with performance HUD active (https://developers.google.com/vr/tools/perfhud) shows lots of reprojection (RAF) that should be 0:

Three.js version
  • Dev
  • All of them
  • Chrome
  • Firefox
  • Internet Explorer
  • All of them
  • Windows
  • macOS
  • Linux
  • Android
  • iOS
Hardware Requirements (graphics card, VR Device, …)


Author: Fantashit

1 thought on “Poor performance on Pixel XL & Daydream

  1. First of all, the Android WebVR implementation unfortunately still has known performance issues, mostly this is due to the presentation pipeline copying pixels which adds fill rate overhead. I’m working on improving that, but this has been taking longer than anticipated.

    But even with that known overhead, simple WebVR applications should still be able to reach 60fps.

    A few things to look out for:

    • The performance overlay costs some performance itself, translucent overlays aren’t cheap to render. This may be enough to cause some dropped frames by itself if the app has tight performance margins.

    • By default, WebVR uses VSync-aligned timing, so if you miss a submission deadline it’ll skip a frame. This generally makes animations smoother, but reduces the framerate and correspondingly increases the reused frame count. As an extreme example, if you consistently need slightly more than 1/60s to render, you’ll drop to 30fps. For performance testing, you can force as-fast-as-possible rendering by setting chrome://flags#webvr-vsync-align to disabled.

    • Performance is highly dependent on rendered resolution, and also somewhat influenced by the field of view. For example, a Pixel XL needs to render more than the non-XL Pixel due to its higher resolution and larger FOV. Applications can override the recommended render resolution to influence this. For example, the https://webvr.info/samples/test-slow-render.html?heavyGpu=1&cubeScale=0.3&workTime=12&standardSize=true&renderScale=1.0 test page sets standardSize=true to choose a base 1024×1024 per eye resolution, independent of device or viewer characteristics, and then applies the renderScale multiplier on top of that. So renderScale=2.0 would draw 2048×2048 pixels per eye for 4x the render cost. (These aren’t standard parameters, this is just an example for comparison purposes.)

    You can use chrome://inspect/?tracing#devices to collect a realtime trace which includes wait times, this can help identify where the bottlenecks are. Here’s a trace of the three.js cubes demo on a Pixel XL using current Chrome Canary:

    three js-cubes-trace

    Note the “WebVR FPS” metric showing 59fps, and the GVR frame acquire/submit times are low which generally indicates it’s not bottlenecked on rendering, and the “WebVR frame time” for “rendering” is around 13ms, so this should be within the 16ms per-frame render budget.

    If you run into performance issues, such a trace can be helpful in identifying what’s going on.

Comments are closed.