Regarding FPS in WebXR.

[Sohan Jyoti Ghosh]

Hi,

What is the acceptable FPS measurement while rendering AR ?

1. Currently we have the ARCoreGL producing the camera texture and frame (pose) data. Reported as WebXR FPS in Trace.

2. There is also the HUD Renderer Compositor FPS data of SubmitCompositorFrame.

3. Then there are is the three.js FPS counter reporting how many times our session rAF callback in invoked. This looks to be tied to the ARCore ProduceFrame (1).

4. NativeViewGLSurfaceEGL::SwapBuffers is the time the real eglSwap is invoked or GpuCommandBufferMsg_SwapBuffersCompleted when the swap is done.

Typically if we set the ARSession update mode to AR_UPDATE_MODE_LATEST_CAMERA_IMAGE, which numbers reflect the real AR FPS.

Thanks,

Sohan

[Bill Orr]

I believe we currently set the ARSession update mode to blocking mode, meaning we get camera frames approximately at 30fps.  That means that (1) and (3) should be roughly 30fps, and should be the same.  This is what I would measure as the frame rate.

Outside of what you render through webgl, there are some steps before it becomes visible on screen - that is (2) and (4).  There may be optimizations so Chrome's compositor doesn't copy the same pixels multiple frames.  My understanding is Chrome's compositor will usually run at ~60fps.

If you are modifying Chromium to use the latest camera image multiple frames, (1) and (3) still represent how many RAF callbacks are invoked, and therefore how many times you render new frames.  However, you'll have to be careful because now nothing will be throttling your frame rate, so you can render faster than the screen refresh rate.  This means that (1) and (3) may be faster than 60fps, even if (2) is 60fps.

[Sohan Jyoti Ghosh]

Thanks, that helps !

[soh...@chromium.org]

Just a thought, for higher end devices supporting ARCore, is it meaningful to throttle the ARCore frame rate to 30 ?

Should we enable ARConfig Update Mode to LATEST_CAMERA_IMAGE and have Chromium control the frame rate to 60 fps (for supporting devices)? and have the default fallback to 30fps, for lower end ones.
There is already some FPS Meter implementation in VR code which maintains a sample queue of all the arriving frames and time stamps.

We can open a crbug and discuss there more, if we are interested.

Thanks,
Sohan

[Klaus Weidner]

We've had discussions about this - the current 30fps limit was mainly intended to keep animations synchronized with camera frames and poses. For static world objects, running more than one animation per camera frame wouldn't be helpful since it would draw the same image based on the same frame.

Moving objects such as particle effects could benefit from a higher animation rate, and in general this is something that would be helpful to support, but I think it would be good to make this an opt-in mode. If the application doesn't need the higher rate, it would just burn battery for no good reason, and could potentially even look worse if it ends up at an animation rate that isn't an even multiple of the camera frame rate.

[Sohan Jyoti Ghosh]

Thanks. 

I have opened crbug.com/890195 for taking the discussion further.

Thanks,

Sohan