Re: Sensor API feedback: OrientationData

On Tue, Mar 6, 2012 at 8:04 AM, Doug Turner <doug.turner@gmail.com> wrote:
> 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'm not convinced that we should do that. But let's see where this
thread is heading.

> 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. ;)

I'm very interested in getting feedback on this. Does anyone know if
keeping the sensors on matters at all battery-wise? Does it draw more
power if results are retrieved 60 times per second vs. twice a second?

If we don't need to worry about this I agree that the API likely
should be significantly changed.

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

This is indeed a problem. However just throwing up our hands and
pushing the problem to authors is the wrong solution IMHO. I suspect
that games are the main use case of this type of API and the feedback
I've received from game developers is that they all end up writing
exactly the same code to use the stream of events into a state
variable which is then polled.

In fact, this is likely not even limited to games. Every time you are
driving graphics based on the device orientation you most likely
should put your rendering code in a requestAnimationFrame callback and
have that code poll the current device orientation state.

Maybe the solution is as simple as having a on/off switch which
controls if events are fired and if the state variable is updated.

/ Jonas

Received on Tuesday, 6 March 2012 22:39:06 UTC