> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre <bmacint...@mozilla.com> > wrote: >> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I >> assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide >> on things like this. Is this correct? > > I believe there's some tricks we could pull on iOS in theory.
Perhaps. But is that part of the discussion? I ask because > > >> From a WebVR perspective, the polyfill (that uses device-orientation) defers >> to the built in WebVR API if it exists. > > So WebVR/XR has its own equivalents for these APIs? I was not aware of > that. No, it’s different: WebVR/XR provide precise 3D orientation and position (assume 3D position tracking is available) of the display. Typically, that’s a Head-Worn Display (ie., a Vive or Rift or whatever). Currently, WebVR has only been implemented only for head-worn displays. The polyfill was used to fill in the gaps; provide “VR” on those paper “cardboard” display holders, for example. Moving forward, WebXR will include the notion of “Magic Window” displays, meaning “you’re holding the device in your hands and it tries to give the appearance of a portal into the virtual or AR world”. So, “tracked 3D content”. For the WebVR/XR api to work, it must provide a super-set of the device-orientation capabilities to the application. There are separate discussions about the security aspects of WebVR/XR: it will not be accessible without permission or user-gesture, as this API is. So, it’s not an “equivalent” API, but is rather providing the information needed to do 3D AR/VR directly, without relying on getting device orientation from this API. > In that case I'm not entirely sure why we'd also pursue new > variants separately. I’m not sure what this means? > > > -- > https://annevankesteren.nl/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
