1217942 - DeviceMotion events are too slow

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Casey Yee]

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.

Comment 1

[Josh Carpenter [:jcarpenter]]

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.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Use the fastest mode for VR-related sensor data on Android

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

Or I guess Casey could try it?

Comment 6

[Josh Carpenter [:jcarpenter]]

Thanks James! Casey is going to test this out tomorrow when he's in the Vancouver office with Kip. We'll follow up!

Comment 7

[(inactive) Jim Chen [:jchen] [:darchons]]

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.

Comment 8

[Josh Carpenter [:jcarpenter]]

> 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?

Comment 9

[Casey Yee]

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.

Comment 10

[Casey Yee]

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?

Comment 11

[Casey Yee]

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.

Comment 12

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 13

[Casey Yee]

The results are pretty good and far better than what we were getting with deviceorientation events.   I think we should get this landed.

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/406fa8040abd

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/406fa8040abd

Comment 16

[Casey Yee]

\o/ yay thanks!