- From: Wolfgang Damm <wolfgang.damm@wikitude.com>
- Date: Mon, 5 Mar 2012 16:37:07 +0100
- To: Andrei Popescu <andreip@google.com>
- Cc: Lars Erik Bolstad <lbolstad@opera.com>, public-geolocation@w3.org, Martin Lechner <martin.lechner@wikitude.com>
- Message-ID: <CAAMsROMzh_nk963x7AYK3LPyT0sMAyBnbBWtDJy=wSv2qy9PVw@mail.gmail.com>
Hi all, thanks for acting on our suggestion that quickly. We are very pleased with the outcome and are looking forward to UAs implementing the deviceorientation API. Thanks, Wolfgang 2012/3/5 Andrei Popescu <andreip@google.com> > Hello, > > We discussed this issue at the face-to-face meeting today. Our > conclusion was that it is very difficult to provide normative language > that would force implementors to guarantee that device orientation > events are generated for changes that are over a specific angular > threshold. > > However, we do understand that the importance of ensuring that > implementations of this spec are as similar as possible. For this > reason, we will add non-normative language that recommends a maximum > angular threshold of 1 degree. > > Thanks, > Andrei > > On Thu, Mar 1, 2012 at 11:03 AM, Wolfgang Damm > <wolfgang.damm@wikitude.com> wrote: > > Hi all, > > > > my name is Wolfgang Damm and I'm working at Wikitude as Lead Software > > Architect. In that role I'm responsible for developing an AR prototype > using > > the DeviceOrientation API. Let me jump right into the discussion. > > > > Lars, thanks for adjusting the cap. > > > > But, I still think that the specification needs to be reworded. The > > pharse "significant change in orientation" is to vague and can be > > interpreted in various ways. Even if it is problematic for our > > usecase, Opera was still well within the specification. > > > > A few usecase come to my mind (and I think you have thought of a few more > > already): > > 1. Augmented Reality > > 2. Games > > 3. Determining Screen orientation (only Up, Down, left, right is of > > interest) > > > > With the current specification I believe only usecase 3. is sufficiently > > covered. For 1. and 2. it is up to the specific UA implementation if they > > are possible. > > > > In my opinion, to cover the different update rate/accuracy needs of > > different usecases without draining battery or degrading performance the > > optimal way would be to let the web app specify how many updates/what > > accuracy it needs. But if this is not an option, there should be a more > > concrete wording of when events should be fired. Something in the line > of: > > > > The event should be fired with a minimum update rate of around 100 ms or > if > > a significant change in orientation occurs.. The definition of a > significant > > change in this context is left to the implementation. > > > > By defining the update rate, a game developer knows what to expect when > > using this API. It also helps in development that the event firing > behavior > > is more similar across different UAs.. > > > > Best, > > > > Wolfgang > > > > 2012/3/1 Lars Erik Bolstad <lbolstad@opera.com> > >> > >> Hi Martin, > >> > >> Sounds like we've capped this at a too high level in Opera's > >> implementation. We'll adjust that. > >> > >> Lars Erik > >> > >> > >> On 29.02.2012 21:40, Doug Turner wrote: > >>> > >>> Hi Martin, > >>> > >>> Thanks for your suggestion. This is an interesting idea, and one > >>> that was discussed. The draft states: > >>> > >>> The event should fire whenever a significant change in orientation > >>> occurs. The definition of a significant change in this context is > >>> left to the implementation. Implementations may also fire the event > >>> if they have reason to believe that the page does not have > >>> sufficiently fresh data. > >>> > >>> I tend to think that Opera filtering at 4 degrees is a UA bug. Maybe > >>> a RFE. I do not think I want to expose tighter control here to web > >>> application. Surely any change to the API allowing such control > >>> could be veto'ed by the UA. Opera could still cap their > >>> notifications at 4 degree changes even though the web application > >>> asked for something tighter. > >>> > >>> It could also be an implementation concern. I know when I fire lots > >>> of events, the over all browser performance suffers. I think UA's > >>> need some flexibility here to provide the best possible performance. > >>> > >>> Thanks again, > >>> > >>> Doug Turner > >>> > >>> > >>> > >>> On Feb 29, 2012, at 6:46 AM, Martin Lechner wrote: > >>> > >>>> Dear members of the Geolocation Working Group, > >>>> > >>>> I am Martin Lechner, CTO of Wikitude, a member of W3C and developer > >>>> of the Wikitude World Browser. > >>>> > >>>> We are currently developing an augmented reality project on > >>>> platforms based on the DeviceOrientation API, and do have a comment > >>>> regarding some specific items in the draft specification. > >>>> > >>>> The current specified update rate of the device orientation event > >>>> is not sufficient for our usecase. Specifically the phrase: “the > >>>> event should fire whenever a significant change in orientation > >>>> occurs.” leaves it up to the implementation when exactly to fire an > >>>> event. > >>>> > >>>> We are already seeing different implementation in the prerelease > >>>> versions of Opera (LAB Opera Mobile) and Mozilla (Aurora). While > >>>> Mozilla reports events quite frequently (which is preferred by us), > >>>> Opera matches the specification and reports events only if there is > >>>> a change of approximately 4 degrees. > >>>> > >>>> Our suggestion would be to let the web developer define how > >>>> accurate the orientation changes should be reported. E.g. like the > >>>> accuracy modes in Geolocation API. For AR it would be nice to have > >>>> a high accuracy to achieve more events to get a smoother, more > >>>> accurate calculation when moving the device. > >>>> > >>>> Best regards, Martin Lechner > >>>> > >>>> -- - - - Martin Lechner CTO > >>>> > >>>> Wikitude GmbH Ginzkeyplatz 11 5020 Salzburg/Austria Phone +43 662 > >>>> 243310 Mobile +43 676 840 856 300 > >>>> > >>>> http://www.wikitude.com > >>>> > >>>> > >>>> > >>> > >> > >> > > > > > > > > -- > > Wolfgang Damm > > Lead Software Architect > > > > > > Wikitude GmbH > > Ginzkeyplatz 11 > > 5020 Salzburg/Austria > > Email: wolfgang.damm@wikitude.com > > Phone: +43 662 243310 > > Mobile: +43 676 840 856 900 > > Web: http://www.wikitude.com > > Twitter: twitter.com/Wikitude > > Facebook: facebook.com/wikitude > > > > Make sure to subscribe to our developer newsletter so you don't miss any > > update about ARchitect. > > > -- Wolfgang Damm Lead Software Architect Wikitude GmbH Ginzkeyplatz 11 5020 Salzburg/Austria Email: wolfgang.damm@wikitude.com Phone: +43 662 243310 Mobile: +43 676 840 856 900 Web: http://www.wikitude.com Twitter: twitter.com/Wikitude Facebook: facebook.com/wikitude Make sure to subscribe to our developer newsletter<http://www.wikitude.com/developer/newsletter> so you don't miss any update about ARchitect.
Received on Monday, 5 March 2012 15:37:42 UTC