1234270 - Improving sensor performance on B2G/Firefox OS

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Performance, defect)

Description

[Szmozsánszky István [:flaki]]

Noticing a rather big performance difference in VR positional sensor update rates between Android and B2G (5 vs 45 FPS on same device), I started digging deeper. As it turned out, most of the sensor APIs suffer from this on B2G, as visible in the tests recorded below: 

https://youtu.be/0rpSwJFtr6k

Both phones are the Sony Xperia Z3 Compact (Aries), the one on the left is flashed with latest Firefox OS Master, the one on the right running factory default Android 5.1.1, and latest Fennec Nightly on top of that. 

Tests were performed via http://flaki.github.io/sensorratetest/ (source code at: https://github.com/flaki/sensorratetest), the first (requestAnimationFrame) test is only there for sanity check (make sure rAF is consistently ~60 FPS, no background processes hog the CPU), and is only needed for the last, PositionSensorVRDevice test, as it uses polling.

The results show that while some Android sensor callbacks can report up to 120 callback/second frequency (and can generally serve a 60 FPS rendering rather well), B2G is rather stable at reporting 5 FPS at most, and this only goes up to 8-9 FPS for DeviceMotion.

After digging through the source, the above 5 FPS update frequency is consistent with the sensor poll thread's polling frequency:
> #define DEFAULT_DEVICE_POLL_RATE 200000000 /*200ms*/ 
http://mxr.mozilla.org/mozilla-central/source/hal/gonk/GonkSensor.cpp#197

...while Android uses several built-in sensor callback facilities:
> sm.registerListener(gi.getSensorEventListener(), gGameRotationVectorSensor, SensorManager.SENSOR_DELAY_FASTEST);
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/GeckoAppShell.java#657 

Android APIs also specify a customizable sensor polling interval for the callbacks where Fennec generally uses the fastest setting (SENSOR_DELAY_FASTEST 0ms artificial delay).

Even not counting the original issue with the VR positioning sensor in bug 1234264, all device-bound OS' with IoT prospects need a stable, robust and fast way to handle the input from the different embedded sensors they contain (or hooked up to), so even if WebVR is not a priority, I think this issue should be prioritized nevertheless.

There is ongoing work in bug 1196221 to migrate sensor access to a separate daemon process, but as the current issue seems to not stem from a hardware limitation, this probably won't solve the problem. I cannot recompile B2G but my guess would be that just by decreasing the poll ratio to something like 160000000 (16ms) could be solved for the time being, but I imagine that raising other issues (e.g. increased battery consumption etc.).

On the long term I think it would be worthy to explore the possibility of implementing some kind of "poll frequency requlation", at least as a Mozilla-open additional parameter or API, to be able to give developers control over device hardware comparable to what Android offers.

Comment 1

[BMO Automation]

Firefox OS is not being worked on