1247082 - [webvr] Strobing effect in Nightly

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Christopher Van Wiemeersch [:cvan]]

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

Comment 1

[:kip (Kearwood Gilbert)]

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

Comment 2

[:kip (Kearwood Gilbert)]

mozregression points to Bug 1064843, continuing to investigate

Comment 3

[:kip (Kearwood Gilbert)]

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.

Comment 4

[:kip (Kearwood Gilbert)]

Attachment: MozReview Request: Bug 1247082 - Suppress rendering of nsBackdropFrame for VR content

- 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/

Comment 5

[:kip (Kearwood Gilbert)]

The try run in the MozReview has passed

Comment 6

[Daniel Holbert [:dholbert]]

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 7

[:kip (Kearwood Gilbert)]

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/

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a4d50664e00

Comment 9

[Xidorn Quan [:xidorn] UTC+11]

So that canvas is always opaque, right?

Comment 11

[Daniel Holbert [:dholbert]]

(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.

Comment 12

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/1a4d50664e00

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

Comment 14

[iprotsyuk]

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

Comment 15

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(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.