Closed Bug 1217942 Opened 4 years ago Closed 4 years ago

DeviceMotion events are too slow

Categories

(Firefox for Android :: General, defect)

44 Branch
Unspecified
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 44
Tracking Status
firefox44 --- fixed

People

(Reporter: caseyyee.ca, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [webvr])

Attachments

(1 file)

DeviceMotion events from Firefox Android are slow:

Example:
http://caseyyee.github.io/DevicemotionTest/

We get delta time of ~20ms on Firefox for Android and ~0.016 for Chrome.

DeviceMotionEvent.interval reports back as 16.6 for Chrome and 100 for Firefox  Android.
Whiteboard: [webvr]
Component: General → Graphics, Panning and Zooming
Product: Firefox → Firefox for Android
Target Milestone: --- → Firefox 44
Version: 44 Branch → Firefox 44
For context: https://github.com/borismus/webvr-polyfill/pull/13

Mobile-friendly WebVR boilerplates are moving to new implementations based on devicemotion, and current FF for Android reports too slowly for this approach.
I don't know where this code lives but this isn't really the right component for this bug. I'm thinking it's either android widget code or the DOM core. snorp, do you know where this should go?
Flags: needinfo?(snorp)
Component: Graphics, Panning and Zooming → General
Flags: needinfo?(snorp)
Josh, this seems to get it down to around 8-9ms for me. Can you try that patch and see what kind of improvement you see? We may have other stuff slowing this down, but it seems we weren't even signing up to get all of the events from Android.
Flags: needinfo?(jcarpenter)
Or I guess Casey could try it?
Flags: needinfo?(caseyyee.ca)
Thanks James! Casey is going to test this out tomorrow when he's in the Vancouver office with Kip. We'll follow up!
Comment on attachment 8679075 [details] [diff] [review]
Use the fastest mode for VR-related sensor data on Android

Review of attachment 8679075 [details] [diff] [review]:
-----------------------------------------------------------------

Hope this doesn't slow down other things.
Attachment #8679075 - Flags: review?(nchen) → review+
> Hope this doesn't slow down other things.

Casey and Kip will test tomorrow (Oct 26) and report back. What is the process for indicating that a bug should be held from landing in m-c until there's been an additional review? Is it simply specifying Casey as a reviewer?
Flags: needinfo?(jcarpenter)
James, I'm seeing similar improvements to 8-9ms, which is great improvement.   Though, unfortunately, it's still too slow for what the the polyfill calls for from devicemotion.

I continue to get: "Invalid timestamps detected. Time step between successive gyroscope sensor samples is very small or not monotonic"

Which is logged out here:
https://github.com/borismus/webvr-polyfill/blob/master/src/fusion-position-sensor-vr-device.js#L104

The polyfill sets the MAX_TIMESTEP to 1ms:
https://github.com/borismus/webvr-polyfill/blob/master/src/util.js#L17-L18

I did try to change the MAX_TIMESTEP to a number that is in range of what we have coming from FF (10), but the results are no good.  I get really spastic and unusable rotation.
Flags: needinfo?(caseyyee.ca)
It could also be that the devicemotion event data that is coming back is not the same as Chrome (and the resulting incorrect rendering).   Will look into this.

James, can we go faster?
Flags: needinfo?(snorp)
Alright, some good news:

If you navigate to:
http://caseyyee.github.io/webvr-boilerplate

It's working quiet well!

DeviceMotionEvent.rotationRate returns numbers that are off by magnitudes from what chrome is reporting.   Dividing the rotationRate.alpha/beta/gamma values by 500000 seemed to closely match what I was seeing in Chrome.

Referring to the w3c spec: http://www.w3.org/TR/orientation-event/#devicemotion
"The rotationRate property must provide the rate of rotation of the hosting device in space. It must be expressed as the rate of change of the angles of the defined in section 4.1 and must be expressed in deg/s."

It seems like we are reporting the correct numbers back as per the spec.

DeviceMotionEvent.accelerationIncludingGravity seems reports back the correct numbers.

I also adjusted MAX_TIMESTEP to 20 in the polyfill, and the results seemed to be quiet good, I suspect a faster sensor readout would still be beneficial in that it should reduce latency even further, but at this point it seems serviceable.
With my patch, I believe we should be getting the sensor values from Android as fast as possible. Maybe we aren't getting them to Gecko fast enough? I can look at that today. I remember Vlad was saying the events were piling up at one point, so we could be dropping some.
Flags: needinfo?(snorp)
The results are pretty good and far better than what we were getting with deviceorientation events.   I think we should get this landed.
https://hg.mozilla.org/mozilla-central/rev/406fa8040abd
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
\o/ yay thanks!
Blocks: 1515780
You need to log in before you can comment on or make changes to this bug.