Re: [deviceorientation] Alternative orientation representations? (#182)

Is the proposal here to retrofit all these features into one specification? And refer to the Orientation Sensor and Magnetometer specifications for these features?

Orientation Sensor provides quaternion and rotation matrix representations:
https://www.w3.org/TR/orientation-sensor/#orientationsensor-quaternion
https://www.w3.org/TR/orientation-sensor/#orientationsensor-populatematrix

Also conversions:
https://www.w3.org/TR/orientation-sensor/#convert-quaternion-to-rotation-matrix
https://www.w3.org/TR/orientation-sensor/#helper-create-quaternion-from-euler-angles

With Magnetometer the compass heading use cases is three lines of code (or with the declination angle, a few more):
https://www.w3.org/TR/magnetometer/#compass

I can share our group's experience that might be helpful. If you try to retrofit these features you'll end up eventually pulling in the rest of the feature dependencies after realizing what it takes to do this properly (speaking from a collective experience, been there...). To take one example: in animation frame loop-based situations, if you can't ask for a sensor update frequency (within safe bounds), you can't match it with the animation frame rate. This means bad user experience, see motion-to-photon delay. What I'm saying is there's a reason why the Generic Sensor-based APIs have a modern shape they have. It was an outcome of a deliberate design process baking in learnings from industry experts in this field over many years. There's a write up by our original author explaining the broader picture (https://www.bocoup.com/work/generic-sensor-api-for-the-web-platform) and a ton of deep technical discussions can be founds from the GH repos spanning back 10+ years.

Circling back to the features proposed: we added these features to the Orientation Sensor, because we heard from web developers this type of abstractions work better with e.g. WebGL or WebGPU, matrix and vector libraries needed to create low-latency motion-driven 3D experiences for the web. Similarly, we heard from web developers that getting compass heading is complicated so we designed the Magnetometer to make that use case simple.

You seem to be paving the same path now we did 10 years ago. The realities of physics haven't changed, so I wouldn't expect different results, except that you are retrofitting to an API that is not designed to be extensible.

-- 
GitHub Notification of comment by anssiko
Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/182#issuecomment-2120317030 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 20 May 2024 12:00:01 UTC