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 platfor
Summary:
WebVR on insecure contexts (i.e. web sites served over non-HTTPS) is deprecated
and will soon stop working in Firefox.
Sites wanting to use WebVR should switch to HTTPS if they have not already.
Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1381645
Link to standard:
https://w3
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 implementa
Please note that disabling the Device Orientation API will also effectively
disable the “WebVR Polyfill”. The “WebVR Polyfill” is a javascript library
that allows browser that otherwise don’t support VR (ie, Fennec) to use
“Cardboard” VR holders to create simple VR experiences. Usage of these
I would add to this Apple’s “OpenGL Profiler”:
https://developer.apple.com/library/content/technotes/tn2178
Cheers,
- Kip
From: Bobby Holley
Sent: June 19, 2017 3:08 PM
To: Chris Cooper
Cc: dev-platform@lists.mozilla.org
Subject: Re: Profiling nightlies on Mac - what tools are used?
Instruments
.
Cheers,
- Kearwood “Kip” Gilbert
From: Alex Gaynor
Sent: May 9, 2017 7:58 AM
To: Kearwood Kip Gilbert
Cc: dev-platform@lists.mozilla.org
Subject: Re: Running mochitest on packaged builds with the sandbox
Hi,
Hmm, VR appears to be an interesting challenge.
To expand a bit more on why mochitest
the sandboxing rules configurable at runtime?
Cheers,
- Kearwood “Kip” Gilbert
From: Alex Gaynor
Sent: May 8, 2017 10:26 AM
To: dev-platform@lists.mozilla.org
Subject: Running mochitest on packaged builds with the sandbox
Hi dev-platform,
Top-line question: Do you rely on being able to run
tion
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,
- Ke
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
sed 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
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, 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
review — I look forward to your feedback!
Cheers,
- Kearwood “Kip” Gilbert
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2016-01-04 4:54 PM, Robert O'Callahan wrote:
> On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking wrote:
>
>> A big problem is sticking HTML/CSS content into WebGL is that WebGL
>> effectively enables reading pixel data through custom shaders and
>> timing attacks.
>>
> If you read
> https://www.k
On 2016-01-04 3:54 PM, Xidorn Quan wrote:
> On Tue, Jan 5, 2016 at 8:46 AM, Kearwood "Kip" Gilbert
> wrote:
>> Hello All,
>>
>> In WebVR, we often present UI as a Head's Up Display (HUD) that floats
>> in front of the user. Additionally, we ofte
On 2016-01-04 4:46 PM, Robert O'Callahan wrote:
> On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert <
> kgilb...@mozilla.com> wrote:
>
>> In WebVR, we often present UI as a Head's Up Display (HUD) that floats
>> in front of the user. Additional
xplore this a bit.
>
> I think that it would be most efficient just to have a meeting about
> these topics, instead of iterating slower via email.
Sounds great, if you don't mind joining in. I'll ping you and get
something set up.
>
> -Jeff
Thanks again, Jeff!
>
> On
uch easier.
If others feel the same, I would also like to follow up with a proposal
to make the captured HTML elements interactive through use of an
explicit "pick buffer" added to canvases.
I look forward to your feedback.
Cheers,
- Kearwood "Kip" Gilbert
Excellent, Kats!!
Perhaps this will also unblock smooth scrolling and scroll snapping for fennec.
Cheers,
- Kearwood “Kip” Gilbert
> On Nov 30, 2015, at 8:37 AM, Kartikaya Gupta wrote:
>
> Hi all,
>
> Just a heads up that I landed the patch to enable APZ on Fennec
> (ni
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
32-bit OSX kernels can indeed run 64-bit applications on 64-bit
hardware. It's not just running the 32-bit code in the fat binaries.
- Kearwood "Kip" Gilbert
On 2015-08-05 4:48 PM, Mike Hommey wrote:
> On Wed, Aug 05, 2015 at 04:34:20PM -0700, Matthew N. wrote:
>> On 20
I would defer to the expert on the subject:
https://imgflip.com/i/o5r8m
- Kip
On 2015-07-07 6:17 PM, David Anderson wrote:
> +1 for removing this. Gecko's use is inconsistent, and outside of Gecko code
> that does use it, I've never seen it used in any other codebase. I've never
> gone to anot
Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix?
Rather than adding support for transforms and projections that involve vertices
behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor affected
call-sites to use Matrix4x4 instead. The remaining references to
ow_bug.cgi?id=1152977 (OSX)
https://bugzilla.mozilla.org/show_bug.cgi?id=1152974 (Linux)
Link to standard:
This feature does not change any API's and takes effect automatically
for existing web content. Other browsers have already shipped with this
enabled, using a similar DEAA implementati
Summary:
Edges of layers with rotations and projections applied through CSS
transforms have stair-step, aliased edges. Visiting the attached URL
demonstrates the aliasing effect.
Applying DEAA (Distance to Edge Anti-aliasing) for transformed layers
enables anti-aliasing without requiring viewpor
. content
is added, moved, deleted, resized), the scroll offset must be modified
to maintain this guarantee.". Support for this is tracked in Bug
1124324 (Perform instant and smooth scrolls to maintain guarantees set
by scroll snapping CSS attributes when content changes) and will be
landed
. content
is added, moved, deleted, resized), the scroll offset must be modified
to maintain this guarantee.". Support for this is tracked in Bug
1124324 (Perform instant and smooth scrolls to maintain guarantees set
by scroll snapping CSS attributes when content changes) and will be
landed separate
useful to track the number of non-Android ARM users.
- Kearwood "Kip" Gilbert
On 2015-02-24 9:52 PM, ishikawa wrote:
> On 2015年02月24日 20:28, Kyle Huey wrote:
>> I'm also not sure why you care about arcane architectures like
>> Itanium, Alpha, and SPARC, since there a
>
> Jonas, I would be really interested in your thoughts. Try as we might (in the
> WebSerial API docs, at least), noone could actually think of a use case where
> providing access to a physical (RS232), or Virtual (VirtualUSB or
> VirtualBluetooth) serial port could be a privacy and/or securit
On Sunday, 25 May 2014 14:57:13 UTC-7, Robert O'Callahan wrote:
> On Mon, May 26, 2014 at 9:47 AM, Robert O'Callahan
> wrote:
>
>
>
> > On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote:
>
> >
>
> >> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote:
>
> >> > I guess what I'm arg
On Tuesday, 27 May 2014 15:12:56 UTC-7, Robert O'Callahan wrote:
> On Wed, May 28, 2014 at 6:14 AM, wrote:
>
>
>
> > Is this behavior acceptable or would it be more desirable to always return
> > the actual scroll position in DOM methods?
>
> All DOM methods that depend on the scroll position
The ScrollBehavior DOM API would certainly be useful by itself and solve some
of our immediate needs (paged B2G home page, for example). I also imagine that
it would not preclude us from implementing the css property in the future if we
implement it carefully.
I would like to hear feedback reg
32 matches
Mail list logo
