- From: Doug Turner <doug.turner@gmail.com>
- Date: Sun, 11 Mar 2012 14:09:09 -0700
- To: "SULLIVAN, BRYAN L" <bs3131@att.com>
- Cc: public-device-apis@w3.org, jmcf@tid.es
- Message-ID: <CAHni0v_SgZgn+WzFUSXMG4TzxcdJW1Q0A_8L3DaKLX==1HW1_A@mail.gmail.com>
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:09:37 UTC