[webvr] Update on WebVR spec, Chrome, and HTTPS
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:
>> 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.
>> On Fri, Sep 9, 2016 at 10:26 AM, Brandon Jones <bajones at google.com>
>>> (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
>>> 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
>>> 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:
>>> <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.
>>> <https://w3c.github.io/webvr/#dom-vrdisplay-getpose> and
>>> <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.
>>> <https://w3c.github.io/webvr/#dom-vrdisplay-depthnear> and
>>> <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.
>>> <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
>>> 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
>>> 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
>>> 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.
>>> The tokens are issued freely and automatically from a short sign up form
>>> 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
>>> 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
>> 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*
>> *Programming 3D Applications in HTML5 and
>> Up and Running*
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/
Read my books!
*Learning Virtual Reality*
*Programming 3D Applications in HTML5 and
Up and Running*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-vr-discuss