Re: DeviceOrientation comments

On 22/07/2010, at 11:43 PM, Steve Block wrote:

> Hi Dean,
> 
> Thanks for the comments.
> 
>> BTW - I'm commenting on http://dev.w3.org/geo/api/spec-source-orientation.html
>> which is currently dated 10 March 2010, although I see comments in the email archives suggesting
>> updates since then.
> I've updated the date on the spec.
> 
>> My main comment/proposal is that Accelerometer Event should include the ability to return
>> rotation around the 3 axes.
> From the interface you provide, I think you're suggesting adding rates
> of rotation, right? What's the use case you have in mind?

We want to expose output from a gyroscope.

> Also, why
> would you add the rates to the AccelerometerEvent, rather than the
> DeviceOrientationEvent, which already reports the values of these
> angles?

I guess it was mostly my confusion on the API. I expected movement (whether shaking or spinning) to be all collected in one event.

> These rates could be determined by numerically differentiating
> the DeviceOrientationEvent data, though it's likely that the
> implementation could give more accurate results.

That's right - you could say the same about accelerometer: why not just differentiate the data coming from GeoLocation?

We really want the accurate data.


>> Along these lines, it would be nice if it also included the direction of gravity so that you could easily
>> determine the acceleration the user is providing.
> I don't think that this is possible. The accelerometer measures the
> forces exerted on it, and this includes the force of gravity. There's
> no way to independently determine the direction of the gravity force
> and hence eliminate it's effects.

That's correct for an accelerometer. But a device with a gyroscope can get the value.

>> The specification currently says that implementations "must set the values of the unknown angles
>> to null", yet the values are defined as doubles.
> I've updated the spec to add the fact that these values are nullable
> (http://dev.w3.org/2006/webapi/WebIDL/#dfn-nullable-type).

My comment was that not all languages can implement a null double. It's fine for Javascript, but not for other languages. It means the generated bindings have to have a non-standard isPropertyNull() or something.

Anyway, I understand it is what is used in GeoLocation, so I'll stop complaining.

>> Lastly, the specification does not provide any way to throttle the rate of incoming events. This
>> could be an implementation detail, but I expect nearly every implementation will want to expose
>> rate control, so it might be worth specifying it.
> In the case of the DeviceOrientationEvent, callbacks are made whenever
> the orientation changes, where the definition of a change, and hence
> any throttling, is left as an implementation detail. I think this
> suffices.

I disagree. I think it is the application that is in a better place to decide what is important. A game might want extremely fine differences to be reported while other applications might only care to look at orientation once a second.

This is why the similar native APIs (Accelerometer on WebOS, Core Motion on iOS, Sensor on Android) all allow some form of control over the sampling rate.


> In the case of the AccelerometerEvent, the thinking was that
> the underlying hardware probably reports the accelerometer data at a
> constant, fixed rate. So any attempt to set the rate would lead to the
> implementation having to interpolate,

I don't think it should interpolate. I think it should simply return the value at that time.

> which could cause problems for
> users of the API which attempt to filter the data. What is the
> motivation for setting the rate, other than avoiding superfluous
> events?

Avoiding superfluous events is important if you have a device that can report very accurate changes very often. You don't want the incoming events to flood the system. It's better to have the throttle in the native layer than in the application - this avoids the overhead of event creation and dispatch.

> 
>> I'm not sure why there is a need to report the interval of incoming events if it is a constant, and
>> can't really be guaranteed anyway. Without the change above there is no way to control it. Also,
>> DOM Events already have a timestamp, so the user can work out the interval themselves.
> The idea was that the interval would be taken from the hardware so
> would be more precise than the timestamp of the DOM Event, which could
> be delayed. The interval is required to allow users of the API to
> perform filtering of the data.

I'm not sure I understand this. If the timestamp isn't accurate because events are delayed, then the data you're getting is also delayed - and now less useful. 

Dean

Received on Thursday, 22 July 2010 23:18:45 UTC