Alternative orientation representations? #182
Comments
|
See also the compass heading example... one would hope that getting a compass heading wouldn't require an entire A4 piece of paper worth of linear algebra, trigonometry, and/or calculus. |
|
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: Also conversions: With Magnetometer the compass heading use cases is three lines of code (or with the declination angle, a few more): 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. |
How is it not extensible? I don't see any issue with bringing the things you listed above to the Device Orientation and Motion spec? Given the lack of interest from other implementers in the additional specifications, it may be more effective to integrate that functionality into the existing ones. The current approach seems to conflict with the TAG's new features design principles. According to these principles: "Before adding items, consider integration with existing, similar capabilities." It appears that there was limited effort to integrate similar capabilities, leading to specifications that are implemented by only one engine and are not adopted by other browser vendors. Wouldn't it be better to add the functionality to this spec (which we should do regardless)? |
The spec contains quite a lot of math to convert the APIs return value into other representations. As show in the examples, that makes for a lot of complex mathematical conversations in JS.
Why don't we allow instead allow developers to request some common alternatives representations? Or provide some static methods to do the conversion (
.toQuaternions()or whatever). That would make the API potentially more developer friendly without needing developers to do a bunch of complicated mathematical conversions themselves.The text was updated successfully, but these errors were encountered: