Re: Some comments about DeviceOrientation draft

Hi Wojciech,

On Feb 16, 2011, at 9:57 AM, Wojciech Masłowski wrote:

> I've read the latest draft of of DeviceOrientation and though it looks quite good I have some questions about it.
>> 4.2 Device Orientation Event
> ...
>> Implementations that are unable to provide absolute values for the three angles may instead provide values relative to some arbitrary orientation, as this may still be of utility. In this case, the absolute property should be set to false. Otherwise, the absolute property should be set to true.
>> 
>> Implementations should set the compassCalibrated property to true if the compass is correctly calibrated. Otherwise, the compassCalibrated property should be set to false. This may imply that user action, such as performing a manual calibration procedure, is required.
> So absolute is set to true if the axes are aligned 100% with the spec and to false if they are not but the device can give us some other orientation data. The compassCalibrated on the other hand gives us information if the Y-axis points directly north. To me it seems that both of these fields mean to developer one thing - the data is not calibrated, you need to do some kind of calibration yourself and I don't really see why we need 2 properties for that instead of one.

The difference is that if you only have a gyroscope/accelerometer without a magnetometer you can get some form of orientation, but never heading data. The calibration of a compass is different from its existence (see my other thread suggesting calibration be changed to an accuracy value).

> 
>> 4.4 Device Motion Event
>> 
>> The DeviceMotionEvent fires on the window object. The event must fire at regular intervals and the interval must be reported, in milliseconds, using the interval attribute of the DeviceMotionEvent object. Note that the interval is a constant for a given implementation.
> I understand why it is required that the events are fired in regular intervals, but I wonder if that interval is available on all the platforms? For example looking at Android API(http://developer.android.com/reference/android/hardware/Sensor.html) there is no direct way
> of obtaining polling rate for a Sensor. Of course it can be extrapolated by user agent implementation by measuring average time between platform events but this can be also achieved in javascript client code if needed. Wouldn't it be better to just include precise timestamp of the platform event in the MotionEvent instead of interval?

All DOM events get a timestamp. Am I misunderstanding you? Do you want the DOM event timestamp to use the system event timestamp?

I originally proposed that the interval be something that the client can request. You might not want to get 100 events a second, for example.

> 
> Other than that I'm not sure if combining accelerometer and rotation sensor into one dom event is a best thing to do either. These events are typically sent separately by the platform so the user agent implementation would have to somehow cache these events and then send them to javascript when it has both acceleration and rotation data.

At least on iOS, we get accelerometer and gyro data in one system event. I'm not sure what other platforms do.

>  This will mean that at least result of one sensor might be late. While the time differences might be minuscule, they might matter. Wouldn't it be better if there were 2 separate events for rotation and accelerometer?

In some way there sort of is: for rotation, you're probably going to use the orientation event rather than the rotationRate on the motion event, because you're more interested in where you are pointing than how fast you are spinning. 

> The last issue is rather cosmetical: why do we need to have 2 separate properties for acceleration : acceleration and accelerationIncludingGravity? Wouldn't it be better to just have additional field includesGravity in Acceleration interface.

This allows an easy way to calculate the gravity vector. If you had only one property you'd know if gravity was included, but not which way is down.

Dean

Received on Wednesday, 16 February 2011 18:16:58 UTC