W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

Re: Sensor API feedback: OrientationData

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 11 Mar 2012 16:48:58 -0500
Message-Id: <AFF424FD-6AC2-49F8-A42C-BF8BF73CAED0@jumis.com>
Cc: "SULLIVAN, BRYAN L" <bs3131@att.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "jmcf@tid.es" <jmcf@tid.es>
To: Doug Turner <doug.turner@gmail.com>
I'm a bit behind on this API; apologies if I'm repeating already discussed or solved issues.

What do you think about having a threshold method?

It'd limit events from firing if they haven't deviated by the threshold amount.



As for the canvas painting issue mentioned earlier in this thread: Canvas authors ought to be using requestAnimationFrame in their techniques when painting reflects sensor data.

High precision pointer events, such as those fires by Wacom tablets (pens) are a good example of why hooking paint calls directly to sensor input can be inefficient and actually reduce precision.

-Charles



On Mar 11, 2012, at 4:09 PM, Doug Turner <doug.turner@gmail.com> wrote:

> Okay... That makes perfect sense. I have shown in a couple threads that we aren't talking about alot of power and there is a way to turn off the gyroscope sensor via removing the listener. I am wondering why this isn't good enough.
> 
> Thanks again!
> 
> Regards,
> Doug
> 
> On Mar 11, 2012 1:40 PM, "SULLIVAN, BRYAN L" <bs3131@att.com> wrote:
> Because the UX impact of an inefficient API (e.g. re battery impact, processor load, etc) will cause users to avoid apps that use the API. Thus the intent of the API (to serve use cases) will not be met.
> 
> Thanks,
> Bryan Sullivan
> 
> On Mar 9, 2012, at 5:59 PM, "Doug Turner" <doug.turner@gmail.com<mailto:doug.turner@gmail.com>> wrote:
> 
> 
> Thanks for the input.  I'd like to know why you think that.
> 
> On Mar 9, 2012 2:27 PM, "SULLIVAN, BRYAN L" <bs3131@att.com<mailto:bs3131@att.com>> wrote:
> 
> I agree with Jose, these types of optimizations are necessary in the API. An API which does not perform some reasonable signal integration (or enable the app to specify the event rate /conditions) will be ineffective.
> 
> 
> 
> 
> -------- Original message --------
> Subject: Re: Sensor API feedback: OrientationData
> From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es<mailto:jmcf@tid.es>>
> To: Doug Turner <doug.turner@gmail.com<mailto:doug.turner@gmail.com>>,"public-device-apis@w3.org<mailto:public-device-apis@w3.org>" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
> CC: Re: Sensor API feedback: OrientationData
> 
> 
> Hi Doug,
> 
> The problem with the Device Orientation Events spec is that there is no
> way for an application to specify how often the event should be raised by
> the UA. For instance Firefox Mobile implementation raises hundreds of
> events per second and when I implemented a Compass app I had to create a
> wrapper to filter out events to avoid collapsing the browser with
> thousands of repaints of the Compass canvas. But in the end battery can be
> drained due to this fact.
> 
> I totally agree that We should not confuse developers, and we should have
> only one mechanism but Device Orientation has flaws.
> 
> Thanks best
> 
> El 02/03/12 20:12, "Doug Turner" <doug.turner@gmail.com<mailto:doug.turner@gmail.com>> escribió:
> 
> >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.
> >
> >
> >
> >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.
> >
> >> it's impossible to tell the difference between gravity and acceleration.
> >
> >True. http://en.wikipedia.org/wiki/Equivalence_principle
> >
> >> is the OrientationData sensor simply a convenience function on top of
> >>the AccelerationData sensor?
> >
> >Both tell you something about the reference.  You really want to know
> >both acceleration and orientation to fully understand what is happening
> >to the reference.  You can't always determine orientation from
> >acceleration or visa versa.
> >
> >> Could someone explain the meaning of the alpha, beta and gamma values?
> >
> >The DeviceOrientation spec goes into great detail about what these values
> >are.
> >
> >
> >
> 
> 
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> 
Received on Sunday, 11 March 2012 21:51:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:29 GMT