W3C home > Mailing lists > Public > public-device-apis-log@w3.org > February 2017

Re: [sensors] Provide the DeviceOrientation sensor

From: Mikhail Pozdnyakov via GitHub <sysbot+gh@w3.org>
Date: Mon, 27 Feb 2017 12:45:47 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-282709964-1488199546-sysbot+gh@w3.org>
> So this API fills-in the buffer synchronously? While the batching 
API will do so async? Seems confusing. Do we really want to offer two 
different APIs for this? Won't we often be in a case where there might
 be more than one sample per AF? e.g. especially if a frame is 
delayed.

IMO we need to split between "getCurrentValue" API returning the 
freshest data from the HW and batching API collecting the previous 
values with weaker latency requirements: these two kinds of APIs have 
to be both used and implemented in different ways.

> Providing quaternions doesn't seem to be specific to 
DeviceOrientation, though. It seems like a data representation 
strategy for a vector plus acceleration combo. Would be useful 
elsewhere too, e.g. for gyroscopes.

On platform level (In 
[Windows](https://msdn.microsoft.com/en-us/library/windows/desktop/dd318987(v=vs.85).aspx)
 and 
[Android](https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ROTATION_VECTOR))
 Sensor APIs use quaternions only to represent device orientation.

-- 
GitHub Notification of comment by pozdnyakov
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/170#issuecomment-282709964 using
 your GitHub account
Received on Monday, 27 February 2017 12:45:54 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:53 UTC