Re: Measuring the gap between the spec and browser implementations

On Mon, Jan 13, 2014 at 5:43 PM, Rob Manson <roBman@buildar.com> wrote:

>
>
>>  Regarding recommendations wrt ranges in the spec. The ranges have been
>> chosen to map uniquely to all possible orientations in space (except for
>> the so-called gimbal lock position). If gamma is in 180,-180 this would
>> introduce a not well defined representation.
>>
>
> Hrm...could you please provide me some pointers to discussion and
> background on this? We really just can't understand the logic here but
> perhaps we're missing some info.
>

There are some comments in the chromium code here:
https://code.google.com/p/chromium/codesearch#chromium/src/content/public/android/java/src/org/chromium/content/browser/DeviceMotionAndOrientation.java&q=DeviceMotionAndOrientation&sq=package:chromium&l=200

For historical perspective there is quite some discussion about the spec on
this very list (public-geolocation@).
A more general but I think very useful explanation:
http://www.sensorplatforms.com/understanding-orientation-conventions-mobile-platforms/


>
> If it's only 90/-90 then from all our development it seems impossible to
> derive a usable position of the phone in landscape mode for up/down
> rotation. I'd be happy to provide working demos and some test code (along
> with some 3D diagrams/animations) that show exactly what we're struggling
> with here.
>
>
Not exactly sure what the issue is here. Would be great if you could
provide more explanation..

I think the spec was designed mostly keeping in mind the screen in standard
orientation. I can imagine why using Euler angles can be tricky when in
landscape. In the scenario when holding the mobile phone vertically in
landscape the angles could be (alpha, beta=0, gamma=-90), trying to rotate
gamma beyond -90 would flip the other two angles to keep gamma in [-90,90)
range, e.g. something like (alpha+180, beta=-180, gamma=89).


>
> roBman