Intent to implement and ship: 'deviceorientation' event relative by default

[Boris Smus]

Contact emails

sm...@google.com

Spec

https://docs.google.com/document/d/1NaXxW5zxB9-RamaL9jx3e_msao-GGrvTnfXJpusWf84/edit#

Summary

1. Change the default behavior of 'deviceorientation' to be relative by default

2. Expose an absolute version of the event through 'absolutedeviceorientation'.

Motivation

1. VR head tracking using DeviceOrientationEvent is currently unusable since Chrome only exposes the absolute version of the event.

2. Safari and Chrome implementations of deviceorientation event are not compatible. Chrome's is absolute by default, Safari's is relative.

Compatibility Risk

Negative risk :) This change improves compatibility between Chrome and Safari.

Augmented reality apps built for Chrome (there are very few) that assume absolute values from the magnetometer will need to change to the new absolutedeviceorientation event.

Ongoing technical constraints

No.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, this is an Android-specific change.

OWP launch tracking bug

http://crbug.com/531610

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5661106970296320

Requesting approval to ship?

Yes. The change is small and already mostly implemented behind a flag: https://chromium.googlesource.com/chromium/src/+/843f048e90026b00dadbca5c34e01694ea943785.

[smaug]

On 09/14/2015 09:13 PM, 'Boris Smus' via blink-dev wrote:
> Contact emails
>
> sm...@google.com <mailto:sm...@google.com>
>
>
> Spec
>
> https://docs.google.com/document/d/1NaXxW5zxB9-RamaL9jx3e_msao-GGrvTnfXJpusWf84/edit#
>
That "spec" doesn't seem to be public.

>
> Summary
>
> 1. Change the default behavior of 'deviceorientation' to be relative by default
>
> 2. Expose an absolute version of the event through 'absolutedeviceorientation'.

I haven't found any W3C or WhatWG draft describing absolutedeviceorientation event, so
other browser vendors can't implement it in interoperable way.



-Olli

>
>
> Motivation
>
> 1. VR head tracking using DeviceOrientationEvent is currently unusable since Chrome only exposes the absolute version of the event.
>
> 2. Safari and Chrome implementations of deviceorientation event are not compatible. Chrome's is absolute by default, Safari's is relative.
>
>
> Compatibility Risk
>
> Negative risk :) This change improves compatibility between Chrome and Safari.
>
>
> Augmented reality apps built for Chrome (there are very few) that assume absolute values from the magnetometer will need to change to the new
> absolutedeviceorientation event.
>
>
> Ongoing technical constraints
>
> No.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> No, this is an Android-specific change.
>
>
> OWP launch tracking bug
>
> http://crbug.com/531610
>
>
> Link to entry on the feature dashboard <https://www.chromestatus.com/>
>
> https://www.chromestatus.com/feature/5661106970296320
>
>
> Requesting approval to ship?
>
> Yes. The change is small and already mostly implemented behind a flag:
> https://chromium.googlesource.com/chromium/src/+/843f048e90026b00dadbca5c34e01694ea943785.
>
>

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

[Rick Byers]

Yes, it's premature to talk about shipping this until there's a proposed spec edit for this spec issue and we've tried to get feedback on it from other vendors.

But LGTM to implement- improving compat with Safari and enabling the VR scenarios are both important IMHO.    More inline.

On Mon, Sep 14, 2015 at 3:34 PM, smaug <sm...@welho.com> wrote:

On 09/14/2015 09:13 PM, 'Boris Smus' via blink-dev wrote:

Contact emails

sm...@google.com <mailto:sm...@google.com>


Spec

https://docs.google.com/document/d/1NaXxW5zxB9-RamaL9jx3e_msao-GGrvTnfXJpusWf84/edit#

That "spec" doesn't seem to be public.

I don't think this doc really says anything more than what's in https://github.com/w3c/deviceorientation/issues/21.  But still, neither are really a precise spec yet so we can't really talk about shipping just yet.

Summary

1. Change the default behavior of 'deviceorientation' to be relative by default

2. Expose an absolute version of the event through 'absolutedeviceorientation'.

I haven't found any W3C or WhatWG draft describing absolutedeviceorientation event, so
other browser vendors can't implement it in interoperable way.



-Olli

Motivation

1. VR head tracking using DeviceOrientationEvent is currently unusable since Chrome only exposes the absolute version of the event.

2. Safari and Chrome implementations of deviceorientation event are not compatible. Chrome's is absolute by default, Safari's is relative.


Compatibility Risk

Negative risk :) This change improves compatibility between Chrome and Safari.

Note however that this does hurt compat with Firefox and Edge (which today both match Chrome in having absolute-by-default events).  I'd like to get their input too.  Hopefully we can get everyone on the same page.

Augmented reality apps built for Chrome (there are very few) that assume absolute values from the magnetometer will need to change to the new
absolutedeviceorientation event.


Ongoing technical constraints

No.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, this is an Android-specific change.

This isn't true.  Chrome Windows (at least) supports DeviceMotion (just tested on Surface Pro 3), and IIRC we may also support it on MacOS and some ChromeOS devices.  We should strive to be consistent across platforms here (but if a platform lacks the sensors for high-quality relative device motion, then it's probably OK to send only absolute).

[PhistucK]

Any reason for not adding the absolute version of the properties to the DeviceOrientation event itself, prefixed with absolute (absoluteFoo)?

Is it because the calculation of the absolute version is expensive (or just comes from a totally different source)? Or is it because it is a different source only on Android?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Beverloo]

+Tim, who I believe has had conversations with other vendors on the subject as well.

Thanks,

Peter

[Boris Smus]

Android implementation-wise, having both absolute and relative data in the payload means multiple sensors streams being subscribed to at the same time. This would definitely incur some overhead, but how much is unclear without having profiled it.

Also, I can't think of a case where you would want both the absolute and relative events at the same time. Because they are exclusive, seems less elegant to stick them both into the same event.

[Philip Jägenstedt]

In Safari, is there any way to get the absolute orientation at all? If there isn't, are there important use cases for this that justify introducing a new event for it? If the absolute orientation is the combination of two underlying sensors, would it make sense to just expose the other sensor (magnetometer) separately?

To me, it seems at least worth considering to just ship the absolute->relative change, since that should improve interoperability, if the amount of stuff that depends on the absolute values (compass and map things?) is known to be large.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

From my previous discussions with Boris it sounds like the absolute use cases are pretty minor (i.e. the change isn't expected to break any real content).  Given that, I'd support doing this in two stages to give more time for debate about the best design for the absolute use cases.

But to answer the immediate suggestion of separate compass heading values, that's what Safari does but isn't something we want to do doing a great job at sensor fusion (to come up with a single orientation value) is very hard and often a feature provided by the underlying OS (eg. Android), not something we want applications to attempt to re-implement themselves.

Rick

[Philip Jägenstedt]

In this case, does Android provide an API for accessing just the
magnetometer, some fused sensor data that would map directly to a
absolutedeviceorientation event, or both?

[Tim Volodine]

Yes this was discussed on other threads as well and Boris and Rick have perfectly summarized the main concerns here.

1. Android has two separate virtual 'sensors' for relative and absolute orientation and the fusion of accelerometer, gyro and potentially magnetometer typically happens close to hardware (either in OS or in the hardware library api).

2. Providing both relative and absolute data in one event seems redundant as it will likely not be used at the same time (and does require separate sensors to be active).

3. Correctly computing absolute orientation in JavaScript from relative + compassHeading seems to be non-trivial and also depends on the definition of compassHeading (correct me if I am wrong).

thanks,

Tim

[Philip Jägenstedt]

Thanks Tim, if that is what the underlying API looks like then I agree
trying to maintain a single event doesn't make sense.

LGTM2 to implement and ship relative for the deviceorientation event,
but if it seems risky or irresponsible to just do that without also
shipping the absolutedeviceorientation event, then let the discussion
continue :)

[Chris Harrelson]

LGTM to implement but not to ship. This needs a real spec, implementation experience and community discussion first.

[Boris Smus]

Please see the updated spec: http://w3c.github.io/deviceorientation/spec-source-orientation.html

It appears that the Chrome implementation is no longer compliant :)

[TAMURA, Kent]

This looks a high-risk change.

I recommend 

 - Wait for feedbacks for absolutedeviceorientation event specification

 - Ship absolutedeviceorientation, and ask web authors to switch to it.

 - Change the behavior of deviceorientation.

If usage of deviceorientation is very low, changing behavior of deviceorientation and adding absolutedeviceorientation at the same time would be ok.

--

TAMURA Kent
Software Engineer, Google

[Rick Byers]

Kent, 

I was initially concerned about this as well, but looking into the details I actually feel changing deviceorientation is quite low risk.  This makes our 'deviceorientation' event behave like Safari's (and so in a way is probably net-fixing a compat bug - since deviceorientation scenarios are most common on Android and iOS).  Other than some AR/VR demos, we don't have any real use cases where the difference even matters (most consumers of deviceorientation don't even realize that Safari and Chrome have subtly different semantics).  If that's true, then I personally think we don't need to add more delay here.

Rick  

[Tim Volodine]

Resurrecting this thread because the proposed changes have been in chrome since m48 under the experimental features flag. Should we enable this by default? Is this lgtm to ship?

Summary of the benefits of enabling this feature by default:

- compatibility of 'deviceorientation' with Safari on iOS (where it is 'relative' by default).

- 'deviceorientation' does not require magnetometer anymore. Which makes it less demanding on hardware and is not distorted by potential external magnetic field (e.g. Cardboard).

- usability of 'deviceorientation' for VR applications (e.g. no 'sensor drift' which occurred in the previous 'absolute' implementation on android)

- dedicated 'deviceorientationabsolute' event for AR applications.

[Rick Byers]

This has also been in the official spec now for awhile: http://w3c.github.io/deviceorientation/spec-source-orientation.html#deviceorientationabsolute.  It sounds like there's been consensus on this design in the WG.  I'm not aware of any other vendors yet shipping the new event, but it's pretty minor and the main value to us is in providing an alternative for developers who wanted our old (not compatible with Safari) behavior.

Please update the chromestatus entry to link to the spec and describe the actual changes: https://www.chromestatus.com/feature/5661106970296320

LGTM1 to ship

[Philip Jägenstedt]

LGTM2

[Chris Harrelson]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.