[webvr] Update on WebVR spec, Chrome, and HTTPS

Tony Parisi tparisi at gmail.com
Thu Sep 29 00:15:37 UTC 2016


Sure and that's why I didn't just freak out and call O'Reilly to stop the
presses... the updates go to e-book first and we can push another one in a
month or so.



On Fri, Sep 9, 2016 at 10:49 AM, Brandon Jones <bajones at google.com> wrote:

> So sorry! I know the timing isn't great, but I would much rather be making
> these changes now than 3-4 months from now after we've got the API in front
> of normal users. Fortunately this isn't a "break the world" transition like
> WebVR 1.0 was, but a gradual deprecation. And most of the principles will
> still apply.
>
> On Fri, Sep 9, 2016 at 10:45 AM Tony Parisi <tparisi at gmail.com> wrote:
>
>> Brandon
>>
>> Wow - many thanks to you and the team for all of this.
>>
>> Um I wish it happened 3 weeks ago before I just pushed an update to my
>> book :0-* but no worries. That's what blogs are for...
>>
>> VERY excited about all of these developments.
>>
>> Tony
>>
>>
>> On Fri, Sep 9, 2016 at 10:26 AM, Brandon Jones <bajones at google.com>
>> wrote:
>>
>>> (This message is a copy of one sent to public-webvr at w3.org. If you're
>>> not already subscribed to that list please take a moment to do so
>>> <http://lists.w3.org/Archives/Public/public-webvr/>! We're moving
>>> official communication about the API to that list.)
>>>
>>>
>>> Hello WebVR community!
>>>
>>> The Chrome team has been a little quiet on the WebVR front recently, and
>>> I apologize for that and thank you for your patience. We’ve been heads down
>>> and working hard to deliver the best experience we can for developers as
>>> soon as we can. Several things have happened recently that will affect what
>>> we’re delivering and how. As such, we wanted to give developers an update.
>>>
>>> Spec changes
>>>
>>> First off, if you haven’t heard already, Microsoft has announced that
>>> they are working on WebVR support in Edge
>>> <https://blogs.windows.com/msedgedev/2016/09/09/webvr-in-development-edge/>.
>>> This means that even wider support for WebVR apps across new and exciting
>>> hardware! It’s a huge deal for web developers, and reiterates the fact that
>>> the best way to reach the widest number of customers in VR will be via the
>>> web.
>>>
>>> Microsoft also approached the WebVR community group with some very
>>> legitimate concerns about how their VR/AR platform would interact with the
>>> API as it exists today. Chief among these concerns was the fact that some
>>> hardware and APIs provide very carefully calibrated projection matrices for
>>> each eye per-frame that should be used for rendering. If those projection
>>> matrices are not used the scene may appear distorted or not align correctly
>>> with the real world, leading to user discomfort of varying degrees.
>>> Computing the projection matrix from the field of view as WebGL has done to
>>> date was simply not sufficient.
>>>
>>> To address this concern and some others that were raised, as well as
>>> ensuring the API can evolve to encompass even more hardware features in the
>>> future, we’re making some changes to the WebVR spec
>>> <https://w3c.github.io/webvr/> prior to launch. I’ve been
>>> affectionately referring to this new version of the spec as “WebVR 1.1”,
>>> but in reality it’s just going to launch as “WebVR”. You can see the
>>> changes in the updated spec, but for those of you who would rather not
>>> analyse source diffs the TL;DR is:
>>>
>>>
>>>    -
>>>
>>>    VRDisplay.getFrameData()
>>>    <https://w3c.github.io/webvr/#dom-vrdisplay-getframedata> has been
>>>    added. It populates a VRFrameData
>>>    <https://w3c.github.io/webvr/#interface-vrframedata> object with a
>>>    pose and left and right eye’s projection and view matrices. To ensure that
>>>    content renders correctly on all WebVR-enabled platforms the projection
>>>    matrices must be used directly and using the view matrices or transform
>>>    based off of them is highly recommended.
>>>    -
>>>
>>>    Your application will be responsible for allocating and providing
>>>    the VRFrameData object. This allows you to more intelligently handle the
>>>    object lifetime and avoid creating unnecessary garbage to collect.
>>>    -
>>>
>>>    VRDisplay.getPose()
>>>    <https://w3c.github.io/webvr/#dom-vrdisplay-getpose> and
>>>    VREyeParameters.fieldOfView
>>>    <https://w3c.github.io/webvr/#dom-vreyeparameters-fieldofview> are
>>>    now deprecated. They will stick around in Chrome’s implementation for a
>>>    while after we ship so that existing content doesn’t break immediately, but
>>>    they may also be left off of other browser’s implementations at their
>>>    discretion. Apps should use getFrameData() (which includes the same pose
>>>    that getPose returns) and the projection matrices it provides instead. If
>>>    your app still needs the field of view it’s recommended that you derive it
>>>    from the projection matrix. We’ll make sure the algorithms to do so are in
>>>    an easy to reference location.
>>>    -
>>>
>>>    VRDisplay.depthNear
>>>    <https://w3c.github.io/webvr/#dom-vrdisplay-depthnear> and
>>>    VRDisplay.depthFar
>>>    <https://w3c.github.io/webvr/#dom-vrdisplay-depthfar> will now be
>>>    used to compute the projection matrices returned by getFrameData().
>>>    Previously these field’s uses were vaguely defined (they were originally
>>>    meant to support positional timewarp) but with this change they’ll become a
>>>    much more important part of the API.
>>>    -
>>>
>>>    VRDisplay.submitFrame()
>>>    <https://w3c.github.io/webvr/#dom-vrdisplay-submitframe> will no
>>>    longer accept a pose. This was more of an aspirational feature than one
>>>    that had a practical current use and caused a fair amount of confusion
>>>    amongst developers. Since not all platforms can support it it’s best to not
>>>    suggest that it’s available. WebVR will assume that all submitted frames
>>>    were rendered with the data supplied in the last call to getFrameData().
>>>    (Which is how basically every WebVR app works already anyway.)
>>>    -
>>>
>>>    VRDisplay.getImmediatePose() has been removed. I don’t think anyone
>>>    actually used this outside of unit tests. In fact, I’ve already taken it
>>>    out of the desktop experimental build and nobody seems to have noticed.
>>>
>>>
>>> We realize that making any code updates for compatibility is a chore,
>>> and apologize for the inconvenience. I hope that you’ll agree, though, that
>>> wider hardware compatibility in the long term is definitely worth a bit of
>>> pain now, before the API has officially launched. We encourage developers
>>> to update your code and give us any feedback you have on the new structure
>>> of the API.
>>>
>>> (I’m also personally curious to know how important compatibility with
>>> the previous API is to the community. Let me know if you have strong
>>> opinions on the subject!)
>>>
>>> There’s actually a lot more than we want to do to expose even more
>>> features of the various VR platforms, but we’ve settled on the above
>>> changes to maximize compatibility while minimizing API churn. Rest assured
>>> we’ve got no shortage of ideas for an eventual WebVR 2.0!
>>>
>>> Code updates
>>>
>>> We’ve got a whole pile of sample code and library updates to go along
>>> with the new spec changes.
>>>
>>>
>>>    -
>>>
>>>    A migration guide
>>>    <https://github.com/w3c/webvr/blob/gh-pages/migration.md> is
>>>    available to walk you through the basic steps needed to update your code.
>>>    -
>>>
>>>    All of the WebVR Samples <https://webvr.info/samples/> have been
>>>    updated to demonstrate proper use of the new API.
>>>    -
>>>
>>>    A shim library
>>>    <https://github.com/w3c/webvr/blob/gh-pages/js/webvr_1_1.js> is
>>>    available that “upgrades” implementations of the previous WebVR API to the
>>>    new one, which should be handy while the browser catch up. (The WebVR
>>>    samples are using it now.)
>>>    -
>>>
>>>    Three.js has been updated with support for the new spec
>>>    <https://github.com/mrdoob/three.js/pull/9655>.
>>>    -
>>>
>>>    The WebVR polyfill will be updated very soon to reflect the new API
>>>    as well.
>>>
>>>
>>> For what it’s worth, I found that I was able to update the WebVR samples
>>> in a few minutes apiece, and in many cases the resulting code was notably
>>> cleaner!
>>>
>>> Schedule changes
>>>
>>> I definitely view these changes as a positive thing for the WebVR
>>> ecosystem, but they are also coming fairly late in the process, and as
>>> a result we’re seeing the need to change our plans regarding launching in
>>> Chrome to allow for the new API to “bake” for a bit. In short, we plan to
>>> make WebVR available first as an Origin Trial
>>> <https://github.com/jpchase/OriginTrials/blob/gh-pages/explainer.md#high-level-design-of-the-solution>.
>>> If you’re not familiar with the concept, it’s a way for Chrome to make
>>> experimental APIs available by default on domains that include an
>>> experimental feature token in the header.
>>> <https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md>
>>> The tokens are issued freely and automatically from a short sign up form
>>> <https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSfO0_ptFl8r8G0UFhT0xhV17eabG-erUWBDiKSRDTqEZ_9ULQ/viewform>,
>>> and all that’s expected from the origins that use it is to provide some
>>> feedback on the feature (bug reports, feature requests, etc.)
>>>
>>> (If you’re not planning on putting WebVR content in front of users
>>> you’ll still be able to turn on WebVR without a token via about:flags for
>>> development or local testing.)
>>>
>>> We feel this is the right call for WebVR in Chrome at this point because
>>> the new API changes have yet to be tested in the wild and we want to ensure
>>> the community has ample time to alert us to any shortcomings or oversights.
>>> At the same time we know that the community has been chomping at the bit to
>>> get WebVR more widely available. Starting as an Origin Trial gives us the
>>> best of both worlds by allowing early adopters to make WebVR content
>>> available by default on their sites without locking us into any spec
>>> guffaws that we might miss in a rush to push through API changes at the
>>> last second.
>>>
>>> I’m still in the process of bringing up experimental builds with the new
>>> API, but I’ll be sure to let everyone know once they’re available!
>>>
>>> Secure Origins
>>>
>>> One final thing that I’m eager to update the community about is Chrome’s
>>> policy when it comes to using WebVR on non-HTTPS domains. I need to
>>> apologize for this one, because after some initial miscommunication behind
>>> the scenes and a public, “Oh, hold on, we spoke too soon,” we left things
>>> in a state of limbo for over a month. I definitely could have done a better
>>> job of communicating while we worked out the details with Chrome’s security
>>> team. I simply wanted to ensure that whatever we said next on the subject
>>> was clear, accurate, and reliable. I’m sorry to leave you all hanging!
>>>
>>> The good news is that we are going to stick with the policy that we
>>> announced last time: WebVR will be allowed on all HTTP domains with a
>>> persistent overlay to alert users to the non-secure origin. That includes
>>> HTTPS content embedded on HTTP domains. This policy is the result of
>>> careful consideration on the part of Chrome’s security team, and I’d like
>>> to thank them for their collaboration and patience while we forge paths
>>> into this new and uncharted territory for the Web.
>>>
>>> From the last round of emails I know that there were several questions
>>> about the behavior and appearance of the security overlay. I’ve put
>>> together a simple demo <https://toji.github.io/webvr-insecure-demo/> to
>>> show the general direction that we’re leaning at this point. Try it with a
>>> WebVR experimental build on desktop or with any mobile device and
>>> Cardboard. It’s not meant to represent the final UX, we’ve still got some
>>> usability testing and refinement to do, but it should give you a decent
>>> idea of where we’re headed.
>>>
>>> It’s worth noting that this policy does not mean that you don’t need to
>>> bother with HTTPS for your WebVR apps. Hosting your content on a secure
>>> origin should be considered a baseline requirement for anything that you
>>> intend to share with the web at large. What this policy enables is a
>>> simpler development cycle, learning curve, and troubleshooting process.
>>> Security is still critical, it can just be step 2 now instead of step 0 for
>>> new projects. Looking for resources on getting started with HTTPS? Check
>>> out Google Developer’s Security and Identity docs
>>> <https://developers.google.com/web/fundamentals/security/>.
>>>
>>> As HTTPS becomes more prevalent and frictionless, and as the development
>>> process on secure origins becomes even easier, the Chrome team does intend
>>> to continue to deprecate powerful APIs in non-secure contexts, and
>>> eventually may lean toward requiring HTTPS for all new APIs. We don’t have
>>> a timeline for deprecating WebVR specifically (might be years down the
>>> road) but please be aware that eventually APIs such as WebVR and Fullscreen
>>> may only be available over secure contexts.
>>>
>>> Thank you!
>>>
>>> So, as you can see we’ve been incredibly busy and aren’t slowing down
>>> any time soon! Thank you for being such an awesome community and for
>>> throwing so much of your incredible talent at an API that’s still
>>> undergoing some growing pains. Bringing VR to the web is just a teensy bit
>>> of a crazy endeavor, but the passion, skill, and creativity that we see
>>> from the community assures us that it will be well worth the effort!
>>>
>>> --Brandon Jones
>>>
>>>
>>> _______________________________________________
>>> web-vr-discuss mailing list
>>> web-vr-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/web-vr-discuss
>>>
>>>
>>
>>
>> --
>>
>>
>> Tony Parisi                             tparisi at gmail.com
>> Follow me on Twitter!             http://twitter.com/auradeluxe
>> Read my blog at                     http://www.tonyparisi.com/
>> Learn WebGL                         http://learningwebgl.com/
>> Mobile                                    415.902.8002
>> Skype                                     auradeluxe
>>
>> Read my books!
>> *Learning Virtual Reality*
>> http://www.amazon.com/Learning-Virtual-Reality-
>> Experiences-Applications/dp/1491922834
>>
>>
>> *Programming 3D Applications in HTML5 and
>> WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966
>> <http://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966>WebGL,
>> Up and Running*
>> http://www.amazon.com/dp/144932357X
>>
>>


-- 


Tony Parisi                             tparisi at gmail.com
Follow me on Twitter!             http://twitter.com/auradeluxe
Read my blog at                     http://www.tonyparisi.com/
Learn WebGL                         http://learningwebgl.com/
Mobile                                    415.902.8002
Skype                                     auradeluxe

Read my books!
*Learning Virtual Reality*
http://www.amazon.com/Learning-Virtual-Reality-Experiences-Applications/dp/1491922834


*Programming 3D Applications in HTML5 and
WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966
<http://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966>WebGL,
Up and Running*
http://www.amazon.com/dp/144932357X
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/web-vr-discuss/attachments/20160929/fac74e54/attachment.html>


More information about the web-vr-discuss mailing list