Consider more aggressively throttling deviceorientation events
Categories
(Core :: DOM: Device Interfaces, enhancement, P3)
Tracking
()
Performance Impact | low |
People
(Reporter: mconley, Unassigned)
References
Details
(Keywords: perf:responsiveness, Whiteboard: [geckoview:p2])
Updated•6 years ago
|
Comment 1•5 years ago
|
||
Adding [qf]
whiteboard tag so the Performance team will review this bug.
Updated•5 years ago
|
Comment 3•5 years ago
|
||
When I test bug 1217942's sample on Chrome today, sampling rate is changed on current Chrome version. But sampling rate seems to be 60fps on Chrome 76.
I guess that device orientation uses 60fps for sampling rate on Blink now?
https://cs.chromium.org/chromium/src/device/vr/orientation/orientation_device.cc?q=set_frequency&l=101&dr=C
https://cs.chromium.org/chromium/src/services/device/public/cpp/generic_sensor/sensor_traits.h?dr=C&g=0&l=14
Comment 4•5 years ago
|
||
rbarker or snorp, do we still need use SENSOR_DELAY_FASTEST
for some sensor types? Although we changed this value from SENSOR_DELAY_GAME
to SENSOR_DELAY_FASTEST
by bug 1217942, Chrome already changed to 60fps (according to https://caseyyee.github.io/DevicemotionTest/) . Since some sites listen deviceorientation event, this event handler is called a lot.
(In reply to Makoto Kato [:m_kato] from comment #4)
rbarker or snorp, do we still need use
SENSOR_DELAY_FASTEST
for some sensor types? Although we changed this value fromSENSOR_DELAY_GAME
toSENSOR_DELAY_FASTEST
by bug 1217942, Chrome already changed to 60fps (according to https://caseyyee.github.io/DevicemotionTest/) . Since some sites listen deviceorientation event, this event handler is called a lot.
Hmm, I guess if Chrome throttles them we can too. Do we care about the webvr polyfill anymore? Probably not?
Updated•5 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Description
•