We're hearing reports of strobing with WebVR in Nightly. https://mail.mozilla.org/pipermail/web-vr-discuss/2016-January/000979.html https://twitter.com/misslivirose/status/696066857350991872 Video created by Bertrand Fan using Oculus DK2 headset (Windows 10, latest GTX 970 drivers, Oculus 0.8 beta runtime, Firefox Nightly): https://www.flickr.com/video_download.gne?ID=24874431336 On 29 Jan 2016, at 15:13, RavenWorks wrote: > Is anyone else getting every other frame on their HMD showing up black > when they try WebVR in Nightly? I tried mozvr.com <http://mozvr.com> on Windows 7 with > Oculus runtime 0.8.0.0. On 1/29/2016 6:24 PM, Chris Car wrote: > Yeah, I got the same effect today, after updating and restarting to the > latest Firefox nightly=85. I am on Win 10, Oculus runtime 0.8 On 1/30/2016 8:12 PM, John Sladek wrote: > I'm also getting the black flashing with Nightly. I'm running windows 7 > Pro and Oculus runtime 0.8. On 2016-02-04 11:42 PM, Brian Peiris wrote: > FYI, I can also reproduce the problem on my Windows 10 machine, AMD R9 380. > Nightly was fine a couple of weeks ago (IIRC). > You can see the problem with this demo: > http://threejs.org/examples/vr_cubes.html

I have reproduce this. I'll do a mozregression and implement a fix.

mozregression points to Bug 1064843, continuing to investigate

The regression has been narrowed down to changset 96460bf88fb3 (Bug 1064843 part 10 - Create and render backdrop frame for top layer frames) I have confirmed that the flashes on alternating frames are this backdrop frame by altering the color.

- The VR specific render path in ContainerLayerComposite does not handle nsBackdropFrame correctly, resulting in a alternate frame strobing effect in the Oculus Headset. As VR content is composed of a Canvas element that is scaled to the extents of the surface the backdrop would otherwise not have an effect for VR content. Review commit: https://reviewboard.mozilla.org/r/34651/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/34651/

The try run in the MozReview has passed

Comment on attachment 8718634 [details] MozReview Request: Bug 1247082 - Suppress rendering of nsBackdropFrame for VR content https://reviewboard.mozilla.org/r/34651/#review31431 At kip's suggestion in IRC, I'll go ahead and steal this review. Just two nits, on the last sentence of the extended commit message: > As VR content is composed > of a Canvas element that is scaled to the extents of the surface > the backdrop would otherwise not have an effect for VR content. (1) Add a comma after "surface". (2) Consider adding a final thought at the end of that sentence, like: ", which means we can simply suppress the backdrop." (I think that's what you're getting at with that sentence, at least, but it's left a little vague right now.)

Comment on attachment 8718634 [details] MozReview Request: Bug 1247082 - Suppress rendering of nsBackdropFrame for VR content Review request updated; see interdiff: https://reviewboard.mozilla.org/r/34651/diff/1-2/

So that canvas is always opaque, right?

(In reply to Xidorn Quan [:xidorn] (UTC+8) (PTO until Feb 14) from comment #9) > So that canvas is always opaque, right? I asked Kip about this in #gfx when reviewing -- it is indeed opaque. > <dholbert> the fullscreen VR canvas element -- is that always opaque? > <kip> dholbert: With current content, always opaque. > In fact, we explicitly clear the render target with black > before rendering the canvas > dholbert: An upcoming API change will be changing the entry > point so that it does not overload RequestFullScreen Also: I imagine when that API change comes, we may not need this ::backdrop-suppressing hack anymore.

Cvan: Is there an easy way to get those folks to verify that this issue is fixed as expected? Thanks!

Not sure about complete verification, but for me the fix worked. No strobing with Oculus Rift anymore.

(In reply to iprotsyuk from comment #14) > Not sure about complete verification, but for me the fix worked. No strobing > with Oculus Rift anymore. Thanks for a prompt verification.