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

Issue 890195 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Nov 6
Cc:
█ lincolnfrog@chromium.org
billorr@chromium.org
bajones@chromium.org
█ sohan.jy...@huawei.com
klausw@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug
Proj-VR
Proj-XR-AR
Proj-XR



Sign in to add a comment

Allow ARCore Config UpdateMode as LATEST_CAMERA_IMAGE.

Project Member Reported by sohanjg@chromium.org, Sep 28 
Currently Chromium allows ARCore to update at Config.UpdateMode BLOCKING i.e. it will wait till a new camera texture is available (~30fps).

We can enable Chromium to configure ARCore's UpdateMode as LATEST_CAMERA_IMAGE. This will be optional for high-end devices and AR Application drawing dynamic animations.

But, with UpdateMode as LATEST_CAMERA_IMAGE, the camera frames are un-throttled. We need to modify Chromium to control the frame rate to device refresh rate (vsync).

Comment 1 by sohanjg@chromium.org, Sep 28 

For the throttling logic, we can in its simplest form check the last frames timestamp at ARCoreGl::ProduceFrame via vr::FPSMeter and early out if they come too quickly.
But, i think the order of call to ProduceFrame are irregular.
For AR (magic window) it should be tied to the window rAF which should be coming at vsync intervals (60 fps).

Comment 2 by johnpallett@chromium.org, Oct 30 

Note: In non-blocking mode the frames are generated as quickly as possible and you can get duplicate frames if your camera fps is lower than your RAF; this doesn't have any benefit and consumes extra processing power.

Can you give more information about why this change would be necessary?

Comment 3 by sohanjg@chromium.org, Oct 31 

Yes, we had some discussions with lincolnfrog@, and billor@.
The 30 fps is an ARCore restrictions, and non-blocking mode doesnt help, because the 'new' camera texture and pose arrives only at 30fps.
But since modern Android HW are capable of 60fps camera updates, we should adapt ARCore to update at a faster rate. 
Maybe an ARCore Feature request.

Comment 4 by lincolnfrog@chromium.org, Nov 6

Status: WontFix (was: Untriaged)
Blocking mode should respect the native camera hardware framerate. If it is not adapting to the camera hardware, that would be a bug to file against ARCore itself.

Comment 5 by lincolnfrog@chromium.org, Nov 6 

Discussed with ARCore - yes, they are currently limiting to 30fps.
►

Sign in to add a comment