Re: Intent to ship: WebVR on macOS

[kgilbert]

On Tuesday, February 27, 2018 at 12:51:46 PM UTC-8, kear...@kearwood.com wrote:
> On Wednesday, September 20, 2017 at 4:30:56 PM UTC-7, Kearwood  Kip  Gilbert 
> wrote:
> > As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has 
> > been developed behind the dom.vr.enabled preference.  We have already 
> > shipped WebVR by default for the Windows platform.  macOS support has been 
> > implemented for several months but disabled by default.  Our WebVR 
> > implementation supports OpenVR for the HTC Vive on macOS High Sierra, which 
> > is now hitting release.
> > This feature was previously discussed in this "intent to implement" thread: 
> > . 
> > Bug to turn on by default: 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
> > Link to standard: https://w3c.github.io/webvr/spec/1.1/
> > Testing: 
> > Automated tests have been implemented and are already active for the macOS 
> > builds in taskcluster.  Platform conformance tests are shared with other 
> > UA’s.
> 
> As of 2018-02-27, I intend to turn WebVR [back] on by default for macOS.  Due 
> to hardware availability for QA, this was disabled before riding to release 
> for FF58 and FF59.  We have since gained QA approval to allow it to ride to 
> release in FF60.
> 
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1438044
> 
> Link to standard:
> https://w3c.github.io/webvr/spec/1.1/
> 
> Testing: 
> Automated tests have been implemented and are already active for the macOS 
> builds in taskcluster.  Platform conformance tests are shared with other UA’s.

Enabling this was delayed / rolled back due to issues with the SteamVR runtime 
on macOS occurring when we disabled the macOS nano-allocator for the Firefox 
process to fix unrelated issues.  Updates to the SteamVR runtime have corrected 
this.

This will be re-re-enabled for FF64 on 2018-10-12.  The new bug to turn on by 
default:

Bug 1476091 ((Re-) Enable WebVR by default for macOS)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on macOS

[kearwood]

On Wednesday, September 20, 2017 at 4:30:56 PM UTC-7, Kearwood  Kip  Gilbert 
wrote:
> As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has 
> been developed behind the dom.vr.enabled preference.  We have already shipped 
> WebVR by default for the Windows platform.  macOS support has been 
> implemented for several months but disabled by default.  Our WebVR 
> implementation supports OpenVR for the HTC Vive on macOS High Sierra, which 
> is now hitting release.
> This feature was previously discussed in this "intent to implement" thread: 
> . 
> Bug to turn on by default: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
> Link to standard: https://w3c.github.io/webvr/spec/1.1/
> Testing: 
> Automated tests have been implemented and are already active for the macOS 
> builds in taskcluster.  Platform conformance tests are shared with other UA’s.

As of 2018-02-27, I intend to turn WebVR [back] on by default for macOS.  Due 
to hardware availability for QA, this was disabled before riding to release for 
FF58 and FF59.  We have since gained QA approval to allow it to ride to release 
in FF60.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1438044

Link to standard:
https://w3c.github.io/webvr/spec/1.1/

Testing: 
Automated tests have been implemented and are already active for the macOS 
builds in taskcluster.  Platform conformance tests are shared with other UA’s.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebVR on macOS

[Kearwood Kip Gilbert]

As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has been 
developed behind the dom.vr.enabled preference.  We have already shipped WebVR 
by default for the Windows platform.  macOS support has been implemented for 
several months but disabled by default.  Our WebVR implementation supports 
OpenVR for the HTC Vive on macOS High Sierra, which is now hitting release.
This feature was previously discussed in this "intent to implement" thread: 
. 
Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
Link to standard: https://w3c.github.io/webvr/spec/1.1/
Testing: 
Automated tests have been implemented and are already active for the macOS 
builds in taskcluster.  Platform conformance tests are shared with other UA’s.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Kearwood "Kip" Gilbert]

We believe that we have addressed the remaining issues and we will turn WebVR 
on by default in Windows, shipping in Firefox 55.

After discussions with the other major browser vendors, we believe that we are 
all on track to ship a compatible version of the WebVR 1.1 draft specification 
and have addressed the issues brought up in this thread.

Additionally, Microsoft announced yesterday that their implementation (with 
whom we share Web Platform Tests) has just shipped with the Creators' Update:
https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/ 


We and other browser engines have expressed an intent to either support 1.1 via 
a polyfill of 2.0 or a side by side implementation, depending on what is easier 
from their engine. If there is very little uptake or we are able to transition 
users to 2.0, then we may be able to deprecate 1.1 entirely. We plan to have 
the discussion around that process in the group later next year, around the 
time when we expect 2.0 to be finalized.

Thanks everyone, within and beyond the MozVR team, for making this possible!

Cheers,

 - Kearwood “Kip” Gilbert

> On Mar 1, 2017, at 12:50 PM, kgilb...@mozilla.com wrote:
> 
> As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has 
> been developed behind the dom.vr.enabled preference and has been enabled by 
> default on Firefox Nightly and Dev Edition since November 2015.  Other UAs 
> shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  
> Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome 
> has enabled WebVR on Android with an Origin Trial.
>  
> This feature was previously discussed in this "intent to ship" thread, for 
> non-release builds:
>  
> https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion 
> 
>  
> Bug to turn on by default:
>  
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368 
> 
>  
> We will support Oculus and HTC Vive by default.  Oculus is already enabled; 
> HTC Vive support with OpenVR has been developed behind the 
> “dom.vr.openvr.enabled” preference and will be turned on with this bug:
>  
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374 
> 
>  
> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ 
> 
>  
> Since the initial implementation, a W3C working group was formed including 
> members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> being conceived.
>  
> Windows only support for WebVR would be enabled by default in Firefox 54.  
> OSX is not yet supported by current VR headsets.  Beta Linux support for HTC 
> Vive has very recently landed, and will be supported by Firefox after the 
> Firefox 54 uplift.
>  
> Cheers,
> Kearwood “Kip” Gilbert
> :kip

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[bajones]

Hi all! I'm a spec editor for WebVR and implementer on Chrome. Wanted to chime 
in on a few points.

Boris: Thanks for the spec bugs you've filed and the concern about improving 
the spec language to ensure consistent implementations between browsers. The 
type of issues you have brought up are exactly the sort of thing that we were 
hearing from Google's side as well and a large part of why we're pursuing what 
we refer to as the "2.0" spec (which is a terrible name given that it's 
intended to ultimately be the only version of the spec, but that's a different 
matter.)

The 2.0 version of the spec currently exists mostly in explainer form right now 
(https://github.com/w3c/webvr/blob/master/explainer.md) while we prep for a TAG 
review. Once that's complete and we've made the appropriate adjustments we'll 
start working on real spec language. It's my intent to focus on making that 
version of the spec far more explicit, algorithmic, and attentive to web 
platform conventions. (I've been frequently referring to 
https://garykac.github.io/procspec/ and 
https://w3ctag.github.io/design-principles/ when figuring out what the spec 
language should look like.)

Given that we know that we have a newer/better version of the spec in the 
pipeline We've been reluctant to personally put much time into fleshing out the 
1.1 version. I don't think I'd classify 1.1 as "stabilized" so much as "no 
longer being invested in". I wouldn't object to updating it with clarifications 
if necessary, though. 

I should also point out that on Google's end we are currently making the 1.1 
spec available via an Origin Trial, but have no plans on enabling it by default 
at this time. It's our intent to continue the Origin Trial while the 2.0 spec 
is finalized, stripping out some deprecated functionality in the meantime to 
prevent developers from growing dependent on it. Once 2.0 is ready we'll 
replace our 1.1 implementation entirely, run the Origin Trial for a little 
longer to gather feedback, and then enable by default.

A few other points of clarification, mostly referring to Kip's original post:
 - We currently have a W3C community group, rather than a full fledged working 
group. 
 - Oculus has been participating in development of the spec but (somewhat to my 
surprise) is not yet an official member of the community group.
 - Samsung is currently shipping an even older version of the API (what we call 
1.0). They are working on 1.1 support now, as I understand it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[kearwood]

On Monday, March 6, 2017 at 12:15:25 PM UTC-8, Boris Zbarsky wrote:
> On 3/6/17 3:03 PM, kearw...@kearwood.com wrote:
> > The underlying VR API's expect this process to persist for the browser's 
> > lifespan and to have mutually-exclusive access to input from the headsets.  
> > It seems that the GPU process is the best fit afaict.
> 
> In case it matters, the GPU process does not have "persist for the 
> browser lifespan" as a goal.  In fact, the whole point of the GPU 
> process is that driver crashes should take down the GPU process but not 
> the browser.  We then restart the GPU process as needed.  On some 
> hardware/software configurations, this is apparently not a rare occurrence.
> 
> -Boris

It would require some work to allow VR to continue after a GPU crash, but 
perhaps such isolation could be useful eventually and predicate a separate VR 
process.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/6/17 3:03 PM, kearw...@kearwood.com wrote:

The underlying VR API's expect this process to persist for the browser's 
lifespan and to have mutually-exclusive access to input from the headsets.  It 
seems that the GPU process is the best fit afaict.


In case it matters, the GPU process does not have "persist for the 
browser lifespan" as a goal.  In fact, the whole point of the GPU 
process is that driver crashes should take down the GPU process but not 
the browser.  We then restart the GPU process as needed.  On some 
hardware/software configurations, this is apparently not a rare occurrence.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[kearwood]

On Friday, March 3, 2017 at 10:42:43 AM UTC-8, Ehsan Akhgari wrote:
> On Fri, Mar 3, 2017 at 12:36 PM,  wrote:
> 
> > Hi Ehsan!
> >
> > I believe all IPC messages can be changed to async except GetSensorState
> > and SubmitFrame.  We cache the results from GetSensorState and re-use it
> > until the next frame.
> >
> 
> Hmm, not sure if I understand correctly.  Did you actually mean "except"
> there?  If we can't guarantee to be able to return the result of
> GetSensorState in the same frame as when it was requested in (which is the
> case on Nightly right now), caching it for the rest of the frame duration
> should be the least of our worries...
For GetSensorState, we are not just concerned with the call completing within 
one frame, but also the timing within a single frame as the value will change 
depending on the timing of the call.  We optimize for late frame pose 
prediction updates by delaying this call as late as possible within one frame 
to get the most accurate prediction of the headset's future pose at the end of 
the frame.  As sync messages have other side-effects, this is a candidate to be 
switched to a different mechanism (such as shared memory).
> 
> 
> > I would like to do some changes to how IPC in WebVR works...
> >
> > First, I'd like to move the parent side of PVRManager to its own thread or
> > possibly a dedicated process.  WebVR can be impacted by busy message
> > queues.  PVRManager is already a top-level protocol and the methods on the
> > parent side are self contained in preparation for this.
> >
> 
> You probably want PBackground for this purpose, although if you're planning
> to communicate with the background parent actor synchronously that may not
> end up being good enough either.  A separate process sounds overkill, and
> probably opens the door to solving more problems that you can probably
> avoid solving (such as dealing with the additional memory usage of a helper
> process.)
The driving need is that the VR messages would not block on any non-webvr 
messages in the queue.

Ideally we won't need a separate process, but if we do, we would start it only 
when necessary.  The underlying VR API's expect this process to persist for the 
browser's lifespan and to have mutually-exclusive access to input from the 
headsets.  It seems that the GPU process is the best fit afaict.
> 
> 
> > Secondly, we may benefit from using another IPC mechanism for sharing
> > per-frame state, which is updating at 90hz and broadcasting the same
> > information to multiple children.  A fundamental difference with WebVR is
> > that children are interested in getting the latest state rather than state
> > in a serial fashion.  A carefully fenced or double buffered structure (like
> > Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here.
> >
> 
> Is this something we can use shared memory for?  Or would the cost of
> locking access to the shared memory undo the benefits?
I would like to explore using shared memory with lockless data structures.  
Chromium does something similar: 
https://chromiumconfessions.blogspot.ca/2016/09/chromium-gamepad-api-and-shared-memory.html

> 
> 
> > For the near-term, I would like to make sure all messages that occur
> > outside of WebVR presentation
> 
> 
> Sorry, I'm not familiar with all of the terminology here.  Which messages
> are those, and what parts of WebVR would still use synchronous IPC
> communication with your suggestion?
GetDisplays is the only IPC that would affect non-webvr sites, and is easy to 
make asynchronous.  It is not timing sensitive and the web-facing api returns a 
promise.

GetSensorState and SubmitFrame would need to be synchronous, but could be using 
a different IPC mechanism.
> 
> 
> > (ie GetDisplays) are async first, then work on a different IPC mechanism
> > and move WebVR's messages into another parent thread / queue..  Would this
> > make sense?
> >
> 
> My first suggestion is to gather some profiles of some WebVR test runs to
> get a better sense of what the current situation looks like.   Still it
> seems to me that we shouldn't have any sync IPC on the path of the DOM APIs
> that are exposed to the page.
I have done a lot of profiling with hardware assisted latency testing to 
measure sub-frame timing of the render loop, including the IPC calls.  I'd like 
to automate this with tests and also get telemetry feedback from the wild.

Thanks for all your constructive feedback!

Cheers,
  - Kip

> 
> Cheers,
> Ehsan
> 
> 
> > Thanks for the feedback!
> >
> > Cheers,
> >   - Kip
> >
> > > On Mar 3, 2017, at 6:47 AM, Ehsan Akhgari 
> > wrote:
> > >
> > > Hi Kearwood,
> > >
> > > I and a few other engineers have been studying the performance of
> > > Firefox for several weeks now as part of the Quantum Flow project and
> > > one of the serious performance issues that we have been finding in
> > > various parts of the browser have been synchronous IPC messages sent
> > > from the content process to the parent pr

Re: Intent to ship: WebVR on Windows in Release

[Ehsan Akhgari]

On Fri, Mar 3, 2017 at 12:36 PM,  wrote:

> Hi Ehsan!
>
> I believe all IPC messages can be changed to async except GetSensorState
> and SubmitFrame.  We cache the results from GetSensorState and re-use it
> until the next frame.
>

Hmm, not sure if I understand correctly.  Did you actually mean "except"
there?  If we can't guarantee to be able to return the result of
GetSensorState in the same frame as when it was requested in (which is the
case on Nightly right now), caching it for the rest of the frame duration
should be the least of our worries...


> I would like to do some changes to how IPC in WebVR works...
>
> First, I'd like to move the parent side of PVRManager to its own thread or
> possibly a dedicated process.  WebVR can be impacted by busy message
> queues.  PVRManager is already a top-level protocol and the methods on the
> parent side are self contained in preparation for this.
>

You probably want PBackground for this purpose, although if you're planning
to communicate with the background parent actor synchronously that may not
end up being good enough either.  A separate process sounds overkill, and
probably opens the door to solving more problems that you can probably
avoid solving (such as dealing with the additional memory usage of a helper
process.)


> Secondly, we may benefit from using another IPC mechanism for sharing
> per-frame state, which is updating at 90hz and broadcasting the same
> information to multiple children.  A fundamental difference with WebVR is
> that children are interested in getting the latest state rather than state
> in a serial fashion.  A carefully fenced or double buffered structure (like
> Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here.
>

Is this something we can use shared memory for?  Or would the cost of
locking access to the shared memory undo the benefits?


> For the near-term, I would like to make sure all messages that occur
> outside of WebVR presentation


Sorry, I'm not familiar with all of the terminology here.  Which messages
are those, and what parts of WebVR would still use synchronous IPC
communication with your suggestion?


> (ie GetDisplays) are async first, then work on a different IPC mechanism
> and move WebVR's messages into another parent thread / queue..  Would this
> make sense?
>

My first suggestion is to gather some profiles of some WebVR test runs to
get a better sense of what the current situation looks like.   Still it
seems to me that we shouldn't have any sync IPC on the path of the DOM APIs
that are exposed to the page.

Cheers,
Ehsan


> Thanks for the feedback!
>
> Cheers,
>   - Kip
>
> > On Mar 3, 2017, at 6:47 AM, Ehsan Akhgari 
> wrote:
> >
> > Hi Kearwood,
> >
> > I and a few other engineers have been studying the performance of
> > Firefox for several weeks now as part of the Quantum Flow project and
> > one of the serious performance issues that we have been finding in
> > various parts of the browser have been synchronous IPC messages sent
> > from the content process to the parent process.  We are tracking the
> > overall issue in bug 1331674, and I had seen WebVR sync IPC messages
> > come up in our measurements as being particularly bad but unfortunately
> > I hadn't gotten a chance to file a bug yet because I didn't realize
> > WebVR is close to being shipped, so sorry for the last minute alarm, but
> > what is our performance story for WebVR?  We have some telemetry probe
> > that suggest that some of the DOM APIs that we expose can potentially
> > blow away your entire frame budget.  For example,
> > PVRManager::Msg_GetSensorState (which, as far as I can tell is how we
> > implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of
> > the slowest ones.  On Nightly, more than 50% of the calls to this
> > synchronous IPC take between 8 to 20ms.  This means calling one WebVR
> > API currently can run the risk of blowing away your entire frame budget.
> > I have filed bug 1344216 for this.
> >
> > I don't have any VR hardware myself so I have done no profiling myself,
> > but what is our performance story here?  I think the current
> > implementation strategy of sending synchronous messages to the parent
> > process isn't going to be viable long term, and honestly it seems to me
> > that for WebVR specifically it may not even be good enough for a first
> > implementation.  Do you have some Gecko Profiler profiles to share,
> > ideally from lower end hardware that can run VR demos so that we can get
> > a sense of what the performance of Gecko on a VR workload looks like?
> > Has there been though of other implementation strategies?
> >
> > (FWIW it has recently became quite clear that sync IPC messages can be
> > *much* worse than sync IO even, we have seen many profiles where sync
> > IPC messages can easily take *seconds*, so even if they show up as super
> > fast on a fast machine when the machine isn't under load, they can
> > essentially take an arbitrary long amo

Re: Intent to ship: WebVR on Windows in Release

[Ehsan Akhgari]

Hi Kearwood,

I and a few other engineers have been studying the performance of
Firefox for several weeks now as part of the Quantum Flow project and
one of the serious performance issues that we have been finding in
various parts of the browser have been synchronous IPC messages sent
from the content process to the parent process.  We are tracking the
overall issue in bug 1331674, and I had seen WebVR sync IPC messages
come up in our measurements as being particularly bad but unfortunately
I hadn't gotten a chance to file a bug yet because I didn't realize
WebVR is close to being shipped, so sorry for the last minute alarm, but
what is our performance story for WebVR?  We have some telemetry probe
that suggest that some of the DOM APIs that we expose can potentially
blow away your entire frame budget.  For example,
PVRManager::Msg_GetSensorState (which, as far as I can tell is how we
implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of
the slowest ones.  On Nightly, more than 50% of the calls to this
synchronous IPC take between 8 to 20ms.  This means calling one WebVR
API currently can run the risk of blowing away your entire frame budget.
 I have filed bug 1344216 for this.

I don't have any VR hardware myself so I have done no profiling myself,
but what is our performance story here?  I think the current
implementation strategy of sending synchronous messages to the parent
process isn't going to be viable long term, and honestly it seems to me
that for WebVR specifically it may not even be good enough for a first
implementation.  Do you have some Gecko Profiler profiles to share,
ideally from lower end hardware that can run VR demos so that we can get
a sense of what the performance of Gecko on a VR workload looks like?
Has there been though of other implementation strategies?

(FWIW it has recently became quite clear that sync IPC messages can be
*much* worse than sync IO even, we have seen many profiles where sync
IPC messages can easily take *seconds*, so even if they show up as super
fast on a fast machine when the machine isn't under load, they can
essentially take an arbitrary long amount of time in less ideal cases...
 I myself have certainly been guilty of adding a fair number of sync IPC
messages before measuring how bad they are in practice.)

Thanks,
Ehsan

On 2017-03-01 3:50 PM, kgilb...@mozilla.com wrote:
> As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has 
> been developed behind the dom.vr.enabled preference and has been enabled by 
> default on Firefox Nightly and Dev Edition since November 2015.  Other UAs 
> shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  
> Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome 
> has enabled WebVR on Android with an Origin Trial.
> 
> This feature was previously discussed in this "intent to ship" thread, for 
> non-release builds:
>  
> https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion
>  
> Bug to turn on by default:
>  
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368
>  
> We will support Oculus and HTC Vive by default.  Oculus is already enabled; 
> HTC Vive support with OpenVR has been developed behind the 
> “dom.vr.openvr.enabled” preference and will be turned on with this bug:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374
> 
> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/
> 
> Since the initial implementation, a W3C working group was formed including 
> members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> being conceived.
>  
> Windows only support for WebVR would be enabled by default in Firefox 54.  
> OSX is not yet supported by current VR headsets.  Beta Linux support for HTC 
> Vive has very recently landed, and will be supported by Firefox after the 
> Firefox 54 uplift.
> 
> Cheers,
> Kearwood “Kip” Gilbert
> :kip
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/2/17 1:52 PM, kearw...@kearwood.com wrote:

I tend to agree with Brandon on this particular issue


That's fine.  I agree with you and Brandon too. ;)  I'm just worried 
about possible interop problems more than anything else at the moment.



Would this issue block release of WebVR in Firefox 54?


To some extent this is a call people more familiar with how this API 
gets used and what interop issues can arise should make.


Note that per 
https://github.com/w3c/webvr/issues/128#issuecomment-283854007 the 
behavior of getFrameData is not interoperable between Edge and Firefox: 
we create new objects hanging off the VRFrameData each time, while they 
mutate all the existing stuff in-place.  This can lead to bugs like code 
that tries to optimize by grabbing a reference to one of the typed 
arrays and then calling getFrameData and assuming the array they are 
referencing is updated (if they test in Edge).  Or not updated and 
represents the previous frame (if they test in Firefox)...


Again, I only spent a few minutes looking at this spec.  What would be 
most helpful here is if someone went through it carefully looking for 
underpecified bits like this, then filed issues as needed and checked 
what browsers actually do in the underspecified cases.  Then we can 
decide whether whatever behavior differences we find are sufficient that 
there is high interop risk from shipping.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[kearwood]

On Thursday, March 2, 2017 at 11:04:07 AM UTC-8, David Baron wrote:
> On Wednesday 2017-03-01 12:50 -0800, kgilb...@mozilla.com wrote:
> > Since the initial implementation, a W3C working group was formed including 
> > members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> > stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> > being conceived.
> 
> There seems to be some disagreement within the WebVR community about
> whether 1.1 was intended to be shipped in stable releases of
> browsers, e.g., in this thread:
> https://twitter.com/aeliasnet/status/837139143276711936
> 
> What's the intent of the WebVR standards community here?
> 
> And is your intend to support the features in 1.1 forever, or to
> take them away at some point?

Chris's response to that tweet sums this up.

Our first implementation of WebVR 2.0 will be a system add-on exposing the new 
API, backed by WebVR 1.1.  WebVR 1.1 implementations will be around for a long 
time and have already been shipped by other UA's.  It will take some time for 
2.0 to be ready to implement as it is still in conception.  When the native 
implementation within Firefox is updated to 2.0, the system add-on will be 
updated to provide backwards compatibility to the WebVR 1.1 API.  At this 
point, WebVR 1.1 will be deprecated but supported as long as needed.  I expect 
the timeframe to be several years of support for WebVR 1.1 API in production.

The vast majority of sites using WebVR are using one of the WebVR polyfills, 
such as:

https://github.com/googlevr/webvr-polyfill

This polyfill provides an even higher level abstraction and enables WebVR on 
platforms without WebVR support, such as phones with a google cardboard holder.

Simply updating this polyfill is all that would be needed for sites that are 
still on the WebVR 1.1 API once eventually deprecated.

> 
> -David
> 
> -- 
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[L. David Baron]

On Wednesday 2017-03-01 12:50 -0800, kgilb...@mozilla.com wrote:
> Since the initial implementation, a W3C working group was formed including 
> members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> being conceived.

There seems to be some disagreement within the WebVR community about
whether 1.1 was intended to be shipped in stable releases of
browsers, e.g., in this thread:
https://twitter.com/aeliasnet/status/837139143276711936

What's the intent of the WebVR standards community here?

And is your intend to support the features in 1.1 forever, or to
take them away at some point?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[kearwood]

On Wednesday, March 1, 2017 at 2:55:53 PM UTC-8, Boris Zbarsky wrote:
> On 3/1/17 5:03 PM, Kip Gilbert wrote:
> > We have worked directly with the other WebVR platform implementers to 
> > ensure compatibility.
> 
> OK, but what is the actual state of that compatibility?
> 
> https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and 
> https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure 
> sound like at least Brandon is not on board with those parts of the 
> current API, and he's one of the spec editors.
I tend to agree with Brandon on this particular issue
> 
> > We have regularly scheduled video calls and F2F meetings to improve the 
> > spec and remove any ambiguity.  We have formed a W3C community working 
> > group.
> 
> That's good.  The question that bothers me is how this interacts with 
> the ship schedule.
> 
> >> [1]  For example, what does the VRFrameData constructor actually do? The 
> >> spec doesn't define it at all.  Where is the VRPose inside supposed to 
> >> come from?  What values will it contain?  I filed 
> >> https://github.com/w3c/webvr/issues/195 on this, but note that I've spent 
> >> all of about 5 minutes skimming the spec and ran into this.  I have _not_ 
> >> done a careful read looking for possible interop problems...
> >
> > VRFrameData is described as receiving the output of the 
> > VRDisplay.getFrameData function:
> 
> Yes, but that's totally unrelated to my question about what the 
> _constructor_ does
On the spec issue, I am working to make the initial values explicit as you have 
suggested: https://github.com/w3c/webvr/issues/195

This has not caused any issues with interoperability, as VRFrameData's values 
are not considered valid until after a call to VRDisplay.getFrameData 
initializes them and returns true indicating it was successful.

Would this issue block release of WebVR in Firefox 54?


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/1/17 5:03 PM, Kip Gilbert wrote:

We have worked directly with the other WebVR platform implementers to ensure 
compatibility.


OK, but what is the actual state of that compatibility?

https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and 
https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure 
sound like at least Brandon is not on board with those parts of the 
current API, and he's one of the spec editors.



We have regularly scheduled video calls and F2F meetings to improve the spec 
and remove any ambiguity.  We have formed a W3C community working group.


That's good.  The question that bothers me is how this interacts with 
the ship schedule.



[1]  For example, what does the VRFrameData constructor actually do? The spec 
doesn't define it at all.  Where is the VRPose inside supposed to come from?  
What values will it contain?  I filed https://github.com/w3c/webvr/issues/195 
on this, but note that I've spent all of about 5 minutes skimming the spec and 
ran into this.  I have _not_ done a careful read looking for possible interop 
problems...


VRFrameData is described as receiving the output of the VRDisplay.getFrameData 
function:


Yes, but that's totally unrelated to my question about what the 
_constructor_ does


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Kip Gilbert]

Sent from my iPad
> On Mar 1, 2017, at 1:32 PM, Boris Zbarsky  wrote:
> 
>> On 3/1/17 3:50 PM, kgilb...@mozilla.com wrote:
>> As of March 1, 2017 I intend to turn WebVR on by default on Windows.
> 
> So flip the pref on Windows only, right?
Yes, flipping pref on only for Windows.  Later, we will be adding support for 
Linux and Android. OpenVR support for Linux is in Beta -- I would like to see 
Linux support come next, in Firefox 55.
> 
> If there is no VR hardware, is the idea that navigator.getVRDisplays() 
> returns a promise resolving to an empty array?
Exactly.  In addition, our implementation waits until either a WebVR API is 
called or a WebVR event listener is added before polling underlying API's for 
devices.
> 
>> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/
> 
> It's a bit worrying to me that this spec is not written down in sufficient 
> detail to be implemented interoperably [1].  How confident are we that what 
> the other browsers are shipping matches what we're shipping?  Are there web 
> platform tests?
We have worked directly with the other WebVR platform implementers to ensure 
compatibility.  We have regularly scheduled video calls and F2F meetings to 
improve the spec and remove any ambiguity.  We have formed a W3C community 
working group.

 A growing number of libraries and sites, including A-Frame, three.js, 
SketchFab, PlayCanvas, and React-VR, already support WebVR and work 
cross-platform.

Automated web platform testing support is landing imminently with Bug 1323328.  
Other UA vendors have expressed interest in sharing conformance tests, inspired 
by WebGL's conformance suite.

> 
> -Boris
> 
> [1]  For example, what does the VRFrameData constructor actually do? The spec 
> doesn't define it at all.  Where is the VRPose inside supposed to come from?  
> What values will it contain?  I filed https://github.com/w3c/webvr/issues/195 
> on this, but note that I've spent all of about 5 minutes skimming the spec 
> and ran into this.  I have _not_ done a careful read looking for possible 
> interop problems...

VRFrameData is described as receiving the output of the VRDisplay.getFrameData 
function:

https://w3c.github.io/webvr/archive/prerelease/1.1/#dom-vrdisplay-getframedata

Thanks for all your feedback!

> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Andrew McCreight]

Last I looked, we didn't have any tests for VRFrameData, FWIW (bug
1317258). I see some now under servo/ but presumably we don't run those.
Maybe I'm missing some.

It would also be good to make sure our internal fuzzers are fuzzing these
APIs to at least catch basic errors.

Andrew

On Wed, Mar 1, 2017 at 1:32 PM, Boris Zbarsky  wrote:

> On 3/1/17 3:50 PM, kgilb...@mozilla.com wrote:
>
>> As of March 1, 2017 I intend to turn WebVR on by default on Windows.
>>
>
> So flip the pref on Windows only, right?
>
> If there is no VR hardware, is the idea that navigator.getVRDisplays()
> returns a promise resolving to an empty array?
>
> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/
>>
>
> It's a bit worrying to me that this spec is not written down in sufficient
> detail to be implemented interoperably [1].  How confident are we that what
> the other browsers are shipping matches what we're shipping?  Are there web
> platform tests?
>
> -Boris
>
> [1]  For example, what does the VRFrameData constructor actually do? The
> spec doesn't define it at all.  Where is the VRPose inside supposed to come
> from?  What values will it contain?  I filed
> https://github.com/w3c/webvr/issues/195 on this, but note that I've spent
> all of about 5 minutes skimming the spec and ran into this.  I have _not_
> done a careful read looking for possible interop problems...
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/1/17 3:50 PM, kgilb...@mozilla.com wrote:

As of March 1, 2017 I intend to turn WebVR on by default on Windows.


So flip the pref on Windows only, right?

If there is no VR hardware, is the idea that navigator.getVRDisplays() 
returns a promise resolving to an empty array?



Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/


It's a bit worrying to me that this spec is not written down in 
sufficient detail to be implemented interoperably [1].  How confident 
are we that what the other browsers are shipping matches what we're 
shipping?  Are there web platform tests?


-Boris

[1]  For example, what does the VRFrameData constructor actually do? 
The spec doesn't define it at all.  Where is the VRPose inside supposed 
to come from?  What values will it contain?  I filed 
https://github.com/w3c/webvr/issues/195 on this, but note that I've 
spent all of about 5 minutes skimming the spec and ran into this.  I 
have _not_ done a careful read looking for possible interop problems...

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebVR on Windows in Release

[kgilbert]

As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has 
been developed behind the dom.vr.enabled preference and has been enabled by 
default on Firefox Nightly and Dev Edition since November 2015.  Other UAs 
shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  
Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome has 
enabled WebVR on Android with an Origin Trial.

This feature was previously discussed in this "intent to ship" thread, for 
non-release builds:
 
https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion
 
Bug to turn on by default:
 
https://bugzilla.mozilla.org/show_bug.cgi?id=1343368
 
We will support Oculus and HTC Vive by default.  Oculus is already enabled; HTC 
Vive support with OpenVR has been developed behind the “dom.vr.openvr.enabled” 
preference and will be turned on with this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1343374

Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/

Since the initial implementation, a W3C working group was formed including 
members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
being conceived.
 
Windows only support for WebVR would be enabled by default in Firefox 54.  OSX 
is not yet supported by current VR headsets.  Beta Linux support for HTC Vive 
has very recently landed, and will be supported by Firefox after the Firefox 54 
uplift.

Cheers,
    Kearwood “Kip” Gilbert
    :kip

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Gervase Markham]

On 29/10/15 17:07, vladi...@mozilla.com wrote:
>> At one point, integrating with available hardware required us to use
>> proprietary code. Is shipping proprietary code in Firefox any part of
>> this plan, or not?
> 
> No.

Awesome! :-)

Gerv


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Ehsan Akhgari]

On 2015-10-29 1:10 PM, vladi...@mozilla.com wrote:

On Monday, October 26, 2015 at 9:39:57 PM UTC-4, Ehsan Akhgari wrote:

First things first, congratulations on getting this close!

What's the status of the specification?  I just had a quick skim and it
seems extremely light on details.


The spec is still a draft, and the API is expected to change significantly 
(specifically the fullscreen window integration is going to change).  The intent to 
ship here is a bit premature; the intent is to pref it on in nightly & aurora, 
not ship it all the way to release.


Oh OK, turning this on on non-release builds sounds good to me.  It 
doesn't really require an intent email...


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Boris Zbarsky]

On 10/29/15 1:10 PM, vladi...@mozilla.com wrote:

The intent to ship here is a bit premature; the intent is to pref it on in nightly 
& aurora, not ship it all the way to release.


OK.  The patches in the "enable it" bugs are enabling on all branches; 
we should probably scale that back to just !RELEASE_BUILD, sounds like.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[vladimir]

On Monday, October 26, 2015 at 9:39:57 PM UTC-4, Ehsan Akhgari wrote:
> First things first, congratulations on getting this close!
> 
> What's the status of the specification?  I just had a quick skim and it 
> seems extremely light on details.

The spec is still a draft, and the API is expected to change significantly 
(specifically the fullscreen window integration is going to change).  The 
intent to ship here is a bit premature; the intent is to pref it on in nightly 
& aurora, not ship it all the way to release.

> There is quite a bit of details missing.  The security model is 
> essentially blank, and the descriptions in section 4 seem to be 
> high-level overviews of what the DOM interfaces do, rather that detailed 
> descriptions that can be used in order to implement the specification.

Yep.

> Also some things that I was expecting to see in the API seem to be 
> missing.  For example, what should happen if the VR device is 
> disconnected as the application is running?  It seems like right now the 
> application can't even tell that happened.

Also something that's coming in an upcoming revision of the API.

> Another question: do you know if Chrome is planning to ship this feature 
> at some point?  Has there been interoperability tests?

They are currently in the same boat as us, shipping it in dev or one-off 
builds.  We're working with them on the specification, and we're generally 
interoperable currently.

- Vlad

> On 2015-10-26 3:19 PM, Kearwood "Kip" Gilbert wrote:
> > As of Oct 29, 2015 I intend to turn WebVR on by default for all
> > platforms. It has been developed behind the dom.vr.enabled preference.
> > A compatible API has been implemented (but not yet shipped) in Chromium
> > and Blink.
> >
> > Bug to turn on by default:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1218482
> >
> > Link to standard: https://mozvr.github.io/webvr-spec/webvr.html
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[vladimir]

On Wednesday, October 28, 2015 at 11:38:26 AM UTC-4, Gervase Markham wrote:
> On 26/10/15 19:19, Kearwood "Kip" Gilbert wrote:
> > As of Oct 29, 2015 I intend to turn WebVR on by default for all
> > platforms. It has been developed behind the dom.vr.enabled preference. 
> > A compatible API has been implemented (but not yet shipped) in Chromium
> > and Blink.
> 
> At one point, integrating with available hardware required us to use
> proprietary code. Is shipping proprietary code in Firefox any part of
> this plan, or not?

No.

 - Vlad
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Gervase Markham]

On 26/10/15 19:19, Kearwood "Kip" Gilbert wrote:
> As of Oct 29, 2015 I intend to turn WebVR on by default for all
> platforms. It has been developed behind the dom.vr.enabled preference. 
> A compatible API has been implemented (but not yet shipped) in Chromium
> and Blink.

At one point, integrating with available hardware required us to use
proprietary code. Is shipping proprietary code in Firefox any part of
this plan, or not?

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Ehsan Akhgari]

First things first, congratulations on getting this close!

What's the status of the specification?  I just had a quick skim and it 
seems extremely light on details.


There is quite a bit of details missing.  The security model is 
essentially blank, and the descriptions in section 4 seem to be 
high-level overviews of what the DOM interfaces do, rather that detailed 
descriptions that can be used in order to implement the specification.


Also some things that I was expecting to see in the API seem to be 
missing.  For example, what should happen if the VR device is 
disconnected as the application is running?  It seems like right now the 
application can't even tell that happened.


Another question: do you know if Chrome is planning to ship this feature 
at some point?  Has there been interoperability tests?


Do we know what the other browser vendors think of the API and the 
specification?


Thanks,
Ehsan

On 2015-10-26 3:19 PM, Kearwood "Kip" Gilbert wrote:

As of Oct 29, 2015 I intend to turn WebVR on by default for all
platforms. It has been developed behind the dom.vr.enabled preference.
A compatible API has been implemented (but not yet shipped) in Chromium
and Blink.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1218482

Link to standard: https://mozvr.github.io/webvr-spec/webvr.html


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebVR

[Jet Villegas]

Let the record state that Firefox is first to deliver Web Virtual Reality
to Planet Earth. On to other (virtual) worlds...

Congratulations, VR Team! \o/

--Jet

On Tue, Oct 27, 2015 at 4:19 AM, Kearwood "Kip" Gilbert <
kgilb...@mozilla.com> wrote:

> As of Oct 29, 2015 I intend to turn WebVR on by default for all platforms.
> It has been developed behind the dom.vr.enabled preference.  A compatible
> API has been implemented (but not yet shipped) in Chromium and Blink.
>
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1218482
>
> Link to standard: https://mozvr.github.io/webvr-spec/webvr.html
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebVR

[Kearwood "Kip" Gilbert]

As of Oct 29, 2015 I intend to turn WebVR on by default for all
platforms. It has been developed behind the dom.vr.enabled preference. 
A compatible API has been implemented (but not yet shipped) in Chromium
and Blink.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1218482

Link to standard: https://mozvr.github.io/webvr-spec/webvr.html


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform