Some comments about DeviceOrientation draft

Hi

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.

> 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?

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. 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?

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.

Regards
Wojciech

-- 
Wojciech Masłowski
Engeneering CORE Wrocław
Opera Software ASA
http://www.opera.com

Received on Wednesday, 16 February 2011 18:00:34 UTC