1786914 - Research if the Sensor Rate in GeckoAppShell for Android can be Slowed Down

Status: NEW

(GeckoView :: General, task)

Description

[Olivia Hall [:olivia]]

The current sensor rate on six sensors in GeckoAppShell is SENSOR_DELAY_FASTEST. In Android 12, use of SENSOR_DELAY_FASTEST requires an additional permission of HIGH_SAMPLING_RATE_SENSORS. This fast rate can also drain the battery quicker.

Ideally, the sensor rate would be adjusted to SENSOR_DELAY_NORMAL; however, this may impact the Sensor API and cause issues with web content such as JS games that make use of these sensor readings.

Suggest researching and testing some websites that make use of the Sensor API or otherwise use sensors through web content and downgrade the sensor rate from HIGH_SAMPLING_RATE_SENSORS to SENSOR_DELAY_NORMAL to see if there is a noticeable impact (or any other unexpected issues).

If SENSOR_DELAY_NORMAL shows too noticeable of an impact on game performance, SENSOR_DELAY_GAME or SENSOR_DELAY_UI may be a good option that still slows down the rate.

If SENSOR_DELAY_FASTEST is removed on all sensors, then the permission HIGH_SAMPLING_RATE_SENSORS may also be removed.

Comment 1

[Makoto Kato [:m_kato]]

I guess that SENSOR_DELAY_FASTEST isn't better value for mobile. Blink seems to use SENSOR_FREQUENCY_NORMAL (= SENSOR_DELAY_NORMAL) as default sensor by https://crbug.com/606766.

But this value is defined by bug 1217942 for WebVR support, so VR mode requires it.

Comment 2

[Olivia Hall [:olivia]]

This bug came to my attention when bug 1932170 was fixed. Kinda think it should maybe go through triage again just to raise awareness. Bug 1780557 has a good overview of how this value came to be and the concerns around it.

Maktoto, do you think it is feasible for us to lower this or is it a hard requirement for WebVR support?

Comment 3

[Makoto Kato [:m_kato]]

(In reply to Olivia Hall [:olivia] from comment #2)

This bug came to my attention when bug 1932170 was fixed. Kinda think it should maybe go through triage again just to raise awareness. Bug 1780557 has a good overview of how this value came to be and the concerns around it.

Maktoto, do you think it is feasible for us to lower this or is it a hard requirement for WebVR support?

Actually, GeckoView VR mode won't be used since Firefox Reality is gone and Wolvic seems to be use Chromium.

Also I re-check current chromium implementation, orientation sensor is 60Hz even if VR and max is 6Hz (this value is same as SENSOR_DELAY_NORMAL). So I think we should use same value as Chromium.

I think 60Hz won't require that permission