Re: Screen Orientation Feedback

2014-08-20 Thread Tim Volodine
Alternatively we could have a unit quaternion representation instead of
screenAlpha/screenBeta/screenGamma. Given that webapps tend to convert the
euler angle representation to something that is easier to compose anyway.

As already mentioned by Rich the angle representations currently differ
somewhat between browsers: Safari uses different ranges for beta, gamma and
there are some issues with Firefox which does not seem to report the
correct angles for some orientations. Unit quaternions are less ambiguous
since each rotation can be represented by either unit quaternion q or -q.

Tim

On Wed, Aug 13, 2014 at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Aug 13, 2014 at 1:38 AM, Rich Tibbett ri...@opera.com wrote:
 
  Do you have any thoughts on providing screen-adjusted devicemotion
  event data also (i.e. acceleration, accelerationIncludingGravity,
  rotationRate)

 It's not something I've thought about, but yeah, it sounds like that
 would make sense.

 / Jonas



Re: Screen Orientation Feedback

2014-08-14 Thread Lars Knudsen
If only someone had pointed out these problems earlier ;)
On Aug 5, 2014 11:17 PM, Jonas Sicking jo...@sicking.cc wrote:

 Hi All,

 I think the current interaction between the screen orientation and
 device orientation specs is really unfortunate.

 Any time that you use the device orientation in order to render
 something on screen, you have to do non-obvious math in order to get
 coordinates which are usable. Same thing if you want to use the device
 orientation events as input for objects which are rendered on screen.

 I would argue that these are the by far most common use cases for

 I agree that the main problem here is that the deviceorientation spec
 defined that their events should be relative to the device rather than
 to the screen. However we can still fix the problem by simply adding

 partial interface DeviceOrientationEvent
 {
   readonly attribute double? screenAlpha;
   readonly attribute double? screenBeta;
   readonly attribute double? screenGamma;
 }

 No new events needs to be defined.

 I guess we can argue that this should be added to the
 DeviceOrientation spec, but that seems unlikely to happen in practice
 anytime soon. I think we would do developers a disservice by blaming
 procedural issues rather than trying to solve the problem.

 I think mozilla would be happy to implement such an addition to the
 DeviceOrientation event (I'm currently checking to make sure). Are
 there other UAs that have opinions (positive or negative) to such an
 addition?

 / Jonas




Re: Screen Orientation Feedback

2014-08-14 Thread Jonas Sicking
Yup. Well.. sounds like people, including you, pointed out these
problems. No idea why it was ignored since I wasn't there.

/ Jonas

On Wed, Aug 13, 2014 at 11:28 PM, Lars Knudsen lar...@gmail.com wrote:
 If only someone had pointed out these problems earlier ;)

 On Aug 5, 2014 11:17 PM, Jonas Sicking jo...@sicking.cc wrote:

 Hi All,

 I think the current interaction between the screen orientation and
 device orientation specs is really unfortunate.

 Any time that you use the device orientation in order to render
 something on screen, you have to do non-obvious math in order to get
 coordinates which are usable. Same thing if you want to use the device
 orientation events as input for objects which are rendered on screen.

 I would argue that these are the by far most common use cases for

 I agree that the main problem here is that the deviceorientation spec
 defined that their events should be relative to the device rather than
 to the screen. However we can still fix the problem by simply adding

 partial interface DeviceOrientationEvent
 {
   readonly attribute double? screenAlpha;
   readonly attribute double? screenBeta;
   readonly attribute double? screenGamma;
 }

 No new events needs to be defined.

 I guess we can argue that this should be added to the
 DeviceOrientation spec, but that seems unlikely to happen in practice
 anytime soon. I think we would do developers a disservice by blaming
 procedural issues rather than trying to solve the problem.

 I think mozilla would be happy to implement such an addition to the
 DeviceOrientation event (I'm currently checking to make sure). Are
 there other UAs that have opinions (positive or negative) to such an
 addition?

 / Jonas





Re: Screen Orientation Feedback

2014-08-13 Thread Rich Tibbett
On Tue, Aug 12, 2014 at 9:59 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Tue, Aug 12, 2014 at 5:35 AM, Rich Tibbett ri...@opera.com wrote:
 On Mon, Aug 11, 2014 at 11:33 PM, Jonas Sicking jo...@sicking.cc wrote:
 I'm not arguing that we remove the relative angle that's in the spec
 right now. I'm arguing that for device orientation events, we should
 provide coordinates relative to the screen as well.

 This topic was filed as an issue against the DeviceOrientation spec in
 March (https://github.com/w3c/deviceorientation/issues/4).

 Interest from implementers is a strong indicator to proceed with such
 spec additions. Active implementer engagement around spec
 clarifications and additions is quite low right now.

 Cool, if we can have this added to an updated DeviceOrientation spec
 then that's definitely the best solution here.

 Though the issue above seems to suggest that the spec would define
 that the existing alpha/beta/gamma properties would be redefined to be
 screen-relative rather than device relative. Is that really going to
 be web compatible?

 I don't think mozilla would feel comfortable leading with such a
 change given our limited influence for mobile content. But if browsers
 with bigger mobile marketshare make such a change we'd definitely
 follow. Do you have any indication that there's interest in that?

 A safer option seems to be to introduce
 screenAlpha/screenBeta/screenGamma (or something similarly named) and
 make those relative to the screen.

Sounds good to me.

 That is something that I'm fairly sure I can make happen in Gecko.

OK. I believe we could implement these properties in Chromium based on
this intent (pending following the correct process there of course).

Do you have any thoughts on providing screen-adjusted devicemotion
event data also (i.e. acceleration, accelerationIncludingGravity,
rotationRate) or do you plan to just stick to providing
screen-adjusted deviceorientation event data for now?

- Rich


 / Jonas



Re: Screen Orientation Feedback

2014-08-13 Thread Jonas Sicking
On Wed, Aug 13, 2014 at 1:38 AM, Rich Tibbett ri...@opera.com wrote:

 Do you have any thoughts on providing screen-adjusted devicemotion
 event data also (i.e. acceleration, accelerationIncludingGravity,
 rotationRate)

It's not something I've thought about, but yeah, it sounds like that
would make sense.

/ Jonas



Re: Screen Orientation Feedback

2014-08-12 Thread Rich Tibbett
On Mon, Aug 11, 2014 at 11:33 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Fri, Aug 8, 2014 at 6:44 AM, Mounir Lamouri mou...@lamouri.fr wrote:
 Maybe this feedback should be more for DeviceOrientation than Screen
 Orientation. There has been a few discussions there
 (public-geolocation).

 This is the type of procedural issues that I'd really rather not get
 caught in. I think it's fine to defer to the DeviceOrientation spec,
 but only if we think there's any chance of it getting added there
 anytime soon. Given that no drafts, to my knowledge, has been
 published for a DeviceOrientation v2, that does not seem to be the
 case.

 Anyway. I am not convinced that adding new properties will really fix
 how developers handle this. I asked around and it seems that native
 platforms do not expose Device Orientation relative to the screen. I am
 not sure why we should expose something different on the Web platform.

 I don't think the fact that other platforms do not supply screen
 relative orientation events is a strong technical argument for why we
 shouldn't.

 I'm definitely in favor of looking at what other platforms do, but not
 with the mindset that what other platforms do is the right thing to
 do, but rather to see if they have good solutions that we could learn
 from. Surely other platforms will make design mistakes, just like we
 do.

 I think we should work on providing developers the right tools in order
 for them to do the right thing.

 I totally agree with this. For all the use cases that I can think of
 for getting the coordinates relative to the screen is more important
 than relative to the device. This includes:

 * A navigation page which shows a map as well as how the device is
 oriented relative to the map.
 * A navigation page which shows a map orientated so that the on-screen
 map matches real world.
 * A game where an in-game character is controlled by tilting the
 device left and right to make the character walk left vs. right.

 I'm sure there are use cases where you need to know the orientation
 relative to the device rather than relative to the screen, they just
 seem to be less common to me.

 Given that, the right tool seems to be to provide the
 DeviceOrientation events relative to the screen and allow them to be
 compensated to be relative to the device if needed.

 Sadly it's too late for that. Authors already have the wrong tool as a
 default since the DeviceOrientation spec is written and implemented
 the way it is.

 However we can at least give authors the right tool as well, by
 introducing screeAlpha etc.

 For example, without the Screen
 Orientation API, they do not know the relative angle between the device
 natural orientation and the screen. This API is not yet widely
 available. Some version of it ships in Firefox and IE but is prefixed.
 It should be in Chrome Beta soon.

 I don't think the right tool to do the right thing in this case
 means give them coordinates in a coordinate system that they don't
 want, and then give them enough information to transform the
 coordinate into the coordinate system that they do want.

 I'm not arguing that we remove the relative angle that's in the spec
 right now. I'm arguing that for device orientation events, we should
 provide coordinates relative to the screen as well.

This topic was filed as an issue against the DeviceOrientation spec in
March (https://github.com/w3c/deviceorientation/issues/4).

Interest from implementers is a strong indicator to proceed with such
spec additions. Active implementer engagement around spec
clarifications and additions is quite low right now.


 / Jonas



Re: Screen Orientation Feedback

2014-08-11 Thread Jonas Sicking
On Fri, Aug 8, 2014 at 6:44 AM, Mounir Lamouri mou...@lamouri.fr wrote:
 Maybe this feedback should be more for DeviceOrientation than Screen
 Orientation. There has been a few discussions there
 (public-geolocation).

This is the type of procedural issues that I'd really rather not get
caught in. I think it's fine to defer to the DeviceOrientation spec,
but only if we think there's any chance of it getting added there
anytime soon. Given that no drafts, to my knowledge, has been
published for a DeviceOrientation v2, that does not seem to be the
case.

 Anyway. I am not convinced that adding new properties will really fix
 how developers handle this. I asked around and it seems that native
 platforms do not expose Device Orientation relative to the screen. I am
 not sure why we should expose something different on the Web platform.

I don't think the fact that other platforms do not supply screen
relative orientation events is a strong technical argument for why we
shouldn't.

I'm definitely in favor of looking at what other platforms do, but not
with the mindset that what other platforms do is the right thing to
do, but rather to see if they have good solutions that we could learn
from. Surely other platforms will make design mistakes, just like we
do.

 I think we should work on providing developers the right tools in order
 for them to do the right thing.

I totally agree with this. For all the use cases that I can think of
for getting the coordinates relative to the screen is more important
than relative to the device. This includes:

* A navigation page which shows a map as well as how the device is
oriented relative to the map.
* A navigation page which shows a map orientated so that the on-screen
map matches real world.
* A game where an in-game character is controlled by tilting the
device left and right to make the character walk left vs. right.

I'm sure there are use cases where you need to know the orientation
relative to the device rather than relative to the screen, they just
seem to be less common to me.

Given that, the right tool seems to be to provide the
DeviceOrientation events relative to the screen and allow them to be
compensated to be relative to the device if needed.

Sadly it's too late for that. Authors already have the wrong tool as a
default since the DeviceOrientation spec is written and implemented
the way it is.

However we can at least give authors the right tool as well, by
introducing screeAlpha etc.

 For example, without the Screen
 Orientation API, they do not know the relative angle between the device
 natural orientation and the screen. This API is not yet widely
 available. Some version of it ships in Firefox and IE but is prefixed.
 It should be in Chrome Beta soon.

I don't think the right tool to do the right thing in this case
means give them coordinates in a coordinate system that they don't
want, and then give them enough information to transform the
coordinate into the coordinate system that they do want.

I'm not arguing that we remove the relative angle that's in the spec
right now. I'm arguing that for device orientation events, we should
provide coordinates relative to the screen as well.

/ Jonas



Re: Screen Orientation Feedback

2014-08-08 Thread Mounir Lamouri
+ri...@opera.com

On Wed, 6 Aug 2014, at 07:14, Jonas Sicking wrote:
 Hi All,
 
 I think the current interaction between the screen orientation and
 device orientation specs is really unfortunate.
 
 Any time that you use the device orientation in order to render
 something on screen, you have to do non-obvious math in order to get
 coordinates which are usable. Same thing if you want to use the device
 orientation events as input for objects which are rendered on screen.
 
 I would argue that these are the by far most common use cases for
 
 I agree that the main problem here is that the deviceorientation spec
 defined that their events should be relative to the device rather than
 to the screen. However we can still fix the problem by simply adding
 
 partial interface DeviceOrientationEvent
 {
   readonly attribute double? screenAlpha;
   readonly attribute double? screenBeta;
   readonly attribute double? screenGamma;
 }
 
 No new events needs to be defined.
 
 I guess we can argue that this should be added to the
 DeviceOrientation spec, but that seems unlikely to happen in practice
 anytime soon. I think we would do developers a disservice by blaming
 procedural issues rather than trying to solve the problem.
 
 I think mozilla would be happy to implement such an addition to the
 DeviceOrientation event (I'm currently checking to make sure). Are
 there other UAs that have opinions (positive or negative) to such an
 addition?

Maybe this feedback should be more for DeviceOrientation than Screen
Orientation. There has been a few discussions there
(public-geolocation).

Anyway. I am not convinced that adding new properties will really fix
how developers handle this. I asked around and it seems that native
platforms do not expose Device Orientation relative to the screen. I am
not sure why we should expose something different on the Web platform. I
think we should work on providing developers the right tools in order
for them to do the right thing. For example, without the Screen
Orientation API, they do not know the relative angle between the device
natural orientation and the screen. This API is not yet widely
available. Some version of it ships in Firefox and IE but is prefixed.
It should be in Chrome Beta soon.

In addition, Tim Volodine recently suggested (in public-geolocation)
that we could add a quaternion representation of the device orientation.
If we could introduce quaternions to the platform and offer tools to do
simple math operations on them, we could narrow the complexity of going
from the device origin to the screen origin to one operation.

Finally, my understanding is that the biggest problem with
DeviceOrientation isn't that the orientation is relative to the device
instead of the screen but the rather high incompatibility. Rich Tibbett
made a great VR demo [1] using DeviceOrientation. I had the chance to
chat with him and he told me that he faced a lot of problems with angles
being very different depending on the device, and the browser. Actually,
I tried to show the demo to a colleague a few days after on an old Nexus
7 and it was completely busted.

The number one problem we should tackle with DeviceOrientation is the
interop issue. The API is currently worthless because if you write it
for one browser on one device, the chance of it working as expected on
another device or browser are fairly low. It is a shame for example that
even Chrome and Firefox running on Android do not have full
interoperability. We should start by working together toward a fully
interoperable implementation (at least for browsers running on Android).
Then we should figure out why some devices are outliers.

[1] http://richtr.github.io/threeVR/examples/vr_basic.html

-- Mounir



Screen Orientation Feedback

2014-08-05 Thread Jonas Sicking
Hi All,

I think the current interaction between the screen orientation and
device orientation specs is really unfortunate.

Any time that you use the device orientation in order to render
something on screen, you have to do non-obvious math in order to get
coordinates which are usable. Same thing if you want to use the device
orientation events as input for objects which are rendered on screen.

I would argue that these are the by far most common use cases for

I agree that the main problem here is that the deviceorientation spec
defined that their events should be relative to the device rather than
to the screen. However we can still fix the problem by simply adding

partial interface DeviceOrientationEvent
{
  readonly attribute double? screenAlpha;
  readonly attribute double? screenBeta;
  readonly attribute double? screenGamma;
}

No new events needs to be defined.

I guess we can argue that this should be added to the
DeviceOrientation spec, but that seems unlikely to happen in practice
anytime soon. I think we would do developers a disservice by blaming
procedural issues rather than trying to solve the problem.

I think mozilla would be happy to implement such an addition to the
DeviceOrientation event (I'm currently checking to make sure). Are
there other UAs that have opinions (positive or negative) to such an
addition?

/ Jonas