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
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
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
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
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
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
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
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
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.
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
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
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
> >
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
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?
>
>
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
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
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
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
___
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
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
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
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
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,
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
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:
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
26 matches
Mail list logo