Comments (8)
- What kind of virtual sensor type to use for the deviceorientation and deviceorientationabsolute events. We can clearly use "accelerometer", "linear-acceleration" and "gyroscope" for DeviceMotionEvent, but there's no clear mapping to one or more sensor types for DeviceOrientationEvent. One could require "accelerometer" and "gyroscope" for relative orientation, for example, but implementations are arguably free to obtain the Euler angles data from the platform in another manner altogether, so I'm tempted to just go with making this specification define additional virtual sensor types, "relative-orientation-data" and "absolute-orientation-data" that takes Euler angles directly.
I'm leaning towards the virtual sensors defined in https://w3c.github.io/orientation-sensor/#automation, the only issue being that they use quaternions instead of Euler angles.
- At the risk of contradicting some of the statements above, using 3 separate sensors ("accelerometer", "linear-acceleration" and "gyroscope") for DeviceMotionEvent may be racy since a new event may fire while one of the sensors is still being updated. In this case, we may need to define a new virtual sensor type that takes all 3 readings at once, and leave it to the implementation to update all readings at once on the platform side.
I don't know about iOS, but on Android the underlying platform API provides accelerometer and gyroscope data independently so these two data sources don't provide readings at the same time and I think it's reasonable for the test interface to reflect that since it is something implementations must deal with.
from deviceorientation.
- What kind of virtual sensor type to use for the deviceorientation and deviceorientationabsolute events. We can clearly use "accelerometer", "linear-acceleration" and "gyroscope" for DeviceMotionEvent, but there's no clear mapping to one or more sensor types for DeviceOrientationEvent. One could require "accelerometer" and "gyroscope" for relative orientation, for example, but implementations are arguably free to obtain the Euler angles data from the platform in another manner altogether, so I'm tempted to just go with making this specification define additional virtual sensor types, "relative-orientation-data" and "absolute-orientation-data" that takes Euler angles directly.
I'm leaning towards the virtual sensors defined in https://w3c.github.io/orientation-sensor/#automation, the only issue being that they use quaternions instead of Euler angles.
The simplest option would then be having some extra sensor types (e.g. "absolute-orientation-euler" and "relative-orientation-euler") with a custom parsing algorithm that reads alpha, beta and gamma values and ensures they are within the ranges we allow for each ([0, 360) for alpha, for example).
I can start working on a PR if this approach (including building it upon the virtual sensor infrastructure from Generic Sensors) sounds sane enough.
from deviceorientation.
Switching the existing tests in WPT to this approach does seem to work, doing this from a spec perspective is a bit tricky.
The idea is to be able to say "we only depend on the Automation section", but the Automation section itself references concepts from other parts of the spec.
For example, if we were to define a per-type virtual sensor metadata entry for "relative-orientation-euler", we'd need to define a corresponding virtual sensor type, which is a sensor type. A sensor type requires one or more IDL interfaces, powerful feature names and permissions policy tokens. Similarly, if we want to use the "accelerometer" virtual sensor type for Device Motion, it means referencing https://w3c.github.io/accelerometer/#accelerometer-automation, which references the Accelerometer sensor type that requires the presence of the Accelerometer IDL interface.
In practice, this is a lot of spec legalese, but it's hard to ignore when changing this specification.
Copying the content from the Generic Sensor spec doesn't fully solve the problem either, as we'd then have conflicting behavior definitions for sensors like accelerometer and gyroscope.
from deviceorientation.
What if we added an Automation section to this spec which hooked into the virtual sensor update algorithms and said "when a quaternion value is provided here, convert it to Euler angles and provide it here"?
from deviceorientation.
I don't think this addresses the underlying problem of virtual sensors depending on and referencing <dfn>
s that are not Automation-related. In the case of using accelerometer and gyroscope types for DeviceMotionEvent, for example, wouldn't it mean this spec would also implicitly depend on the Accelerometer sensor type and IDL interface?
from deviceorientation.
Hmm, I think if I tweak the Automation section in the Generic Sensor spec, I can remove the explicit link between virtual sensors and sensor types in the per-type virtual sensor metadata mapping by making the sensor type itself optionally have the same string that identifies a virtual sensor type.
The Device Orientation spec side would still be a bit hand-wavy, but I guess that's to be expected.
from deviceorientation.
Agreed, the challenge is that the Generic Sensors spec has "platform sensor" as a core concept which can be replaced by a virtual sensor while this specification what the source of the data is.
from deviceorientation.
Hmm, I think if I tweak the Automation section in the Generic Sensor spec, I can remove the explicit link between virtual sensors and sensor types in the per-type virtual sensor metadata mapping by making the sensor type itself optionally have the same string that identifies a virtual sensor type.
The Device Orientation spec side would still be a bit hand-wavy, but I guess that's to be expected.
I've made an attempt to do this in w3c/sensors#475. The Device Orientation side is in #124.
from deviceorientation.
Related Issues (20)
- Broken references in DeviceOrientation Event Specification
- Behavior when event data cannot be provided is underspecified HOT 3
- DeviceOrientationEvent.absolute's value when data cannot be obtained
- Wide review tracker HOT 20
- Accessibility Checklist HOT 2
- Internationalization Checklist HOT 3
- Same origin S&P requirement conflicts with Permissions Policy integration HOT 3
- Guidance needed: how to acquire compass headings in a future-compatible manner? HOT 3
- "Status of this document" section needs to reflect join deliverable status HOT 8
- How to check when permission is denied? HOT 8
- Fix the build HOT 3
- Do we really need 3 permissions policies? HOT 7
- Abstract away underlying sensors HOT 2
- Fully active checks
- Alternative orientation representations? HOT 4
- Combined permission request is problematic HOT 6
- fire an orientation event need to use the dictionary HOT 1
- How reliable is interval? HOT 4
- Goodies from Accelerometer, Motion, Orientation, Gyro specs to bring over
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from deviceorientation.