Re: Sensor API feedback: OrientationData

Jonas,
Thanks for your feedback.  It is kind of a shame that there is a lot of overlap with the Sensor API.  I am happy that Tran is going to drop the Device Motion bits from this DAP spec.


I answered some of your concerns here - but do feel free to raise them on the Device Orientation WG mailing list -- 

First, about power usage.  A noble goal for sure.  If you want to reduce battery, you can simply stop listening for the event.  The implementations basically will eventually power down the sensor.  This isn't exactly spec'ed out, but we could put some non-normative text in the spec as some implementers note.  Would that be helpful to you?

Also, just to put some data behind your power concern.  What is the cost of keeping the Gryo on?  I do not have current data, but a AMOLED display costs about 1-3 watts depending on color and brightness.  Most gyro's measure in the mW.  So, you probably have a bigger impact changing the color scheme of your web app on power, than turning off the gyro… Of course, all things cost and reduction of the cost of all sensors is good… but the implementations give you a way -- just stop listening to the events. ;)

Second, about your use case that some applications do not need events all of the time.  There are going to be millions of use cases that we can generate.  Some will need one event every year, others will need an event every 100ms.  If you read the Device Orientation mailing list, you'll see AR people concerned that we aren't sending events fast enough. ;)  Javascript callbacks can filter what they don't need, they can also remove listeners to stop the stream of orientation changes.  We can make this API really complex, but that isn't where my head is at…. I want something damn simple and using just DOM events basically gets you there.

Third, the problem with adding public accessors to every Device Motion property, if you think about it, is that we don't always know what the answer is.  Sometimes, we have to power up the accelerometer or gyro and wait.  So, there are times when the ua can't return an answer.  I don't think we should throw or something awful like that.  Therefore, we do not have anything like that.  Also, according to the Device APIs Requirements and Design Decisions (http://dev.w3.org/2009/dap/api-reqs/) methods (like a getter for device motion property) "must support asynchronous, cancelable operation".  So, maybe with the Joy stick API you don't have to power things up, but with many sensors you do.

I hope this helps.

Doug Turner
 

On Mar 6, 2012, at 11:46 AM, Jonas Sicking wrote:

> On Fri, Mar 2, 2012 at 11:12 AM, Doug Turner <doug.turner@gmail.com> wrote:
>> Hi Jonas, Tran,
>> 
>> I am concerned that there is overlap between the Sensor Api and the DeviceOrientaiton Spec:
>>   http://dev.w3.org/geo/api/spec-source-orientation.html
>> 
>> I worry that web developers will not know which API to use.  Tran, have you looked at our draft specification?  I am wondering how we can make these two efforts result in something that is consistent and pleasing to developers.
> 
> There's two problems that I see with the current DeviceOrientation
> drafts which the SensorAPI solves, though only one is major.
> 
> My understanding was that was benefit in being able to control how
> often the sensor should be queried in order to reduce battery
> consumption. For something like a game you might not care about
> battery consumption a lot, but you do want very exact movement
> detection. But for something like a star-map application, you might be
> ok with a couple of times a second and are much more concerned about
> battery consumption.
> 
> This could be fixed in the DeviceOrientation spec by introducing some
> global attribute which lets the page control how often the sensor
> should be checked. However that means if there are several different
> independent subsystems running on the page, they'll fight over control
> of that one global property.
> 
> The only way to really solve this problem is to have an API similar to
> the Sensor API. I.e. a separate object instantiated where events are
> fired and where you have control over timing of when that event is
> fired.
> 
> The need to control how often a sensor is checked is something that I
> fairly recently learned about, so I don't yet fully understand all the
> aspects of it. If it's not correct at all it's more or less free to
> get data at maximum speed as soon as the sensor is turned on, then
> that might indeed change things.
> 
> 
> The second is really a much simpler issue. I've gotten feedback, in
> particular from game developers, that event-based APIs for input data
> is generally the wrong model. What games generally want to be able to
> do is to check "what's the state of the input controls right now"
> rather than "tell me when the controls change". That way it's much
> easier to integrate the input state into the normal game loop.
> 
> What developers end up doing is to have a simple event handler for
> input-state-changes which simply set a variable somewhere and then
> that variable is checked in the normal game loop. This isn't a big
> deal at all but it would be nice to avoid all developers having to
> jump through this hoop.
> 
> When designing the Joystick API we took this into account so the
> current API makes the current state available as properties, and then
> fires an event when the state changes.
> 
> This would be easy to fix in the DeviceOrientation API by simply
> exposing the current orientation/acceleration as a property somewhere
> (note that this shouldn't synchronously poll the sensor, it would
> simply cache the result of the latest firing event).
> 
>> Answer to questions Jonas raised:
>> 
>>> I'm having trouble understanding the difference between the OrientationData and AccelerationData sensors.
>> 
>> They are measuring different things.  Orientation has to do with rotation about an axis measured by a gyro.  Acceleration will tell you change in speed measured by an accelerometer.
> 
> That's the Gyroscope sensor.
> 
> The OrientationData sensor provides the device's current orientation
> in relation to the direction of gravity.
> 
>>> Could someone explain the meaning of the alpha, beta and gamma values?
>> 
>> The DeviceOrientation spec goes into great detail about what these values are.
> 
> If the Sensor API intends to use the same meaning as what's defined in
> the DeviceOrientation spec, it seems like the alpha component will
> always be 0.
> 
> / Jonas

Received on Tuesday, 6 March 2012 16:05:15 UTC