New issue
Advanced search Search tips

Issue 667327 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug
Proj-VR
Proj-XR
Proj-XR-VR



Sign in to add a comment

WebVR Presentation leads to empty black screen

Project Member Reported by mthiesse@chromium.org, Nov 21 2016

Issue description

Some small fraction of the time (~10%) when you present a webVR page, you're taken to an empty black screen. Exiting and re-presenting usually fixes the issue, unless you're very unlucky.

Would be nice to get this fixed for M56.

 

Comment 1 by sko...@chromium.org, Nov 21 2016

Labels: ReleaseBlock-Stable

Comment 2 by sko...@chromium.org, Nov 22 2016

Cc: klausw@chromium.org bajones@chromium.org
This is marked as P0 to fix for M56 but no one is assigned to work on it.  Klaus/Brandon, could one of you pick this up?

Comment 3 by sko...@chromium.org, Nov 22 2016

Labels: -Pri-0 Pri-1

Comment 4 by klausw@chromium.org, Nov 22 2016

Status: Started (was: Available)
I'm investigating.

FYI, there's a separate GVR issue that can also lead to VR mode failure tracked in http://b/33071750 : If you call setVrModeEnabled without calling DaydreamApi::launchInVr, or you've failed to meet the timeout deadline, the DON flow is triggered, and tries to launch your activity with a standard intent, which fails to launch the non-exported activity.

Comment 5 by bshe@chromium.org, Nov 28 2016

talked with Micheal offline.
 It could happen without this error message:
" W ActivityManager: Permission Denial: starting Intent { cat=[com.google.intent.category.DAYDREAM] flg=0x34010000 cmp=org.chromium.chrome/.browser.ChromeTabbedActivity } from null (pid=-1, uid=10075) not exported from uid 10116"
This suggests the root cause of the black screen is different from b/33071750.

It is also more reproducible on Pixel XL while conneted to desktop through usb. I haven't be able to reproduce it on my Pixel phone.
Also, the black screen isn't exactly empty, it has the close and gear button, and the divider of left/right eye.

Comment 6 by sko...@chromium.org, Nov 28 2016

Owner: klausw@chromium.org
Progress, thanks to Bill and Brian for the extra pair of eyes and discussion.

Issue seems to be that GVR's reprojection stops working permanently for some reason. I added a hack to do SetReprojection(GVR_REPROJECTION_NONE) for every second submitted frame, and this resulted in a flashing display with every second presented view being black (apart from showing the divider / X / config button).

The pixel encoded pose was sometimes being read as 16777215 == 0xffffff for
all-white pixels. I'm adding various sanity checks to prevent attempts
to use uninitialized or already-used poses.

11-30 18:36:52.281  6900  9341 V chromium: [VERBOSE2:vr_shell.cc(556)] GetPixelEncodedPoseIndex start
11-30 18:36:52.293  6900  9341 V chromium: [VERBOSE2:vr_shell.cc(568)] GetPixelEncodedPoseIndex end
11-30 18:36:52.293  6900  9341 V chromium: [VERBOSE2:vr_shell.cc(653)] DrawFrame: poseIndex=16777215

To clarify, the issue appears to be that using an invalid pose in a GVR submit appears to permanently break reprojection for that GVR instance.
Project Member

Comment 9 by bugdroid1@chromium.org, Dec 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/772bdaaac52114f3ebbc7626a3c630a3918b03d0

commit 772bdaaac52114f3ebbc7626a3c630a3918b03d0
Author: klausw <klausw@chromium.org>
Date: Fri Dec 02 02:10:46 2016

WebVR: avoid race conditions for partially-initialized display

The GvrNonPresentingDelegate was acting as a pseudo VRDisplay device and
reporting successful requestPresent even though vital information such
as render resolution is not available yet.

Instead of the "fallback" 2048x1024 resolution, report a 0x0 resolution
so that other code can recognize this as an invalid device and defer
actions such as resizing.

One specific issue was that a vrpresentchange was getting fired prematurely,
leading to wrong canvas sizing by the JS application.

BUG= 667327 

Review-Url: https://codereview.chromium.org/2544713002
Cr-Commit-Position: refs/heads/master@{#435824}

[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/chrome/browser/android/vr_shell/vr_shell.cc
[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/chrome/browser/android/vr_shell/vr_shell.h
[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/chrome/browser/android/vr_shell/vr_shell_delegate.cc
[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/device/vr/android/gvr/gvr_delegate.h
[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/device/vr/android/gvr/gvr_device.cc
[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/772bdaaac52114f3ebbc7626a3c630a3918b03d0/third_party/WebKit/Source/modules/vr/VRDisplay.h

Project Member

Comment 10 by bugdroid1@chromium.org, Dec 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/490f4294847d427265ae138de9932926d61b885e

commit 490f4294847d427265ae138de9932926d61b885e
Author: klausw <klausw@chromium.org>
Date: Fri Dec 02 05:57:59 2016

WebVR: Add sanity checks for decoded pose index values

We seem to be getting glitches in the display pipeline that
manifest as all-white pixels for a few frames before regular
rendering starts. These get misinterpreted as an invalid
pose index, and apparently supplying a wrong pose to GVR
permanently breaks reprojection for that instance.

Add sanity checks to help identify and avoid bad pose values
during initialization.

BUG= 667327 

Review-Url: https://codereview.chromium.org/2541023003
Cr-Commit-Position: refs/heads/master@{#435866}

[modify] https://crrev.com/490f4294847d427265ae138de9932926d61b885e/chrome/browser/android/vr_shell/vr_shell.cc
[modify] https://crrev.com/490f4294847d427265ae138de9932926d61b885e/chrome/browser/android/vr_shell/vr_shell.h
[modify] https://crrev.com/490f4294847d427265ae138de9932926d61b885e/device/vr/android/gvr/gvr_device_provider.cc
[modify] https://crrev.com/490f4294847d427265ae138de9932926d61b885e/third_party/WebKit/Source/modules/vr/VRDisplay.cpp

Labels: Merge-Request-56

Comment 12 by dimu@chromium.org, Dec 2 2016

Labels: -Merge-Request-56 Merge-Approved-56 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M56 (branch: 2924)
Project Member

Comment 13 by bugdroid1@chromium.org, Dec 2 2016

Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/578a9ee9e7c36be402e089e9dd83d97546752827

commit 578a9ee9e7c36be402e089e9dd83d97546752827
Author: Brandon Jones <bajones@chromium.org>
Date: Fri Dec 02 21:41:59 2016

WebVR: avoid race conditions for partially-initialized display

The GvrNonPresentingDelegate was acting as a pseudo VRDisplay device and
reporting successful requestPresent even though vital information such
as render resolution is not available yet.

Instead of the "fallback" 2048x1024 resolution, report a 0x0 resolution
so that other code can recognize this as an invalid device and defer
actions such as resizing.

One specific issue was that a vrpresentchange was getting fired prematurely,
leading to wrong canvas sizing by the JS application.

BUG= 667327 

Review-Url: https://codereview.chromium.org/2544713002
Cr-Commit-Position: refs/heads/master@{#435824}
(cherry picked from commit 772bdaaac52114f3ebbc7626a3c630a3918b03d0)

Review URL: https://codereview.chromium.org/2550803002 .

Cr-Commit-Position: refs/branch-heads/2924@{#301}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/chrome/browser/android/vr_shell/vr_shell.cc
[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/chrome/browser/android/vr_shell/vr_shell.h
[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/chrome/browser/android/vr_shell/vr_shell_delegate.cc
[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/device/vr/android/gvr/gvr_delegate.h
[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/device/vr/android/gvr/gvr_device.cc
[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/578a9ee9e7c36be402e089e9dd83d97546752827/third_party/WebKit/Source/modules/vr/VRDisplay.h

Project Member

Comment 14 by bugdroid1@chromium.org, Dec 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff9b716dacc4003878af2122770986ce03f574f6

commit ff9b716dacc4003878af2122770986ce03f574f6
Author: Brandon Jones <bajones@chromium.org>
Date: Fri Dec 02 21:48:51 2016

WebVR: Add sanity checks for decoded pose index values

We seem to be getting glitches in the display pipeline that
manifest as all-white pixels for a few frames before regular
rendering starts. These get misinterpreted as an invalid
pose index, and apparently supplying a wrong pose to GVR
permanently breaks reprojection for that instance.

Add sanity checks to help identify and avoid bad pose values
during initialization.

BUG= 667327 

Review-Url: https://codereview.chromium.org/2541023003
Cr-Commit-Position: refs/heads/master@{#435866}
(cherry picked from commit 490f4294847d427265ae138de9932926d61b885e)

Review URL: https://codereview.chromium.org/2552443002 .

Cr-Commit-Position: refs/branch-heads/2924@{#302}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/ff9b716dacc4003878af2122770986ce03f574f6/chrome/browser/android/vr_shell/vr_shell.cc
[modify] https://crrev.com/ff9b716dacc4003878af2122770986ce03f574f6/chrome/browser/android/vr_shell/vr_shell.h
[modify] https://crrev.com/ff9b716dacc4003878af2122770986ce03f574f6/device/vr/android/gvr/gvr_device_provider.cc
[modify] https://crrev.com/ff9b716dacc4003878af2122770986ce03f574f6/third_party/WebKit/Source/modules/vr/VRDisplay.cpp

Owner: billorr@chromium.org
Labels: -VR-Demo VR-FF
Status: Fixed (was: Started)
I've been unable to repro this today with all relevant fixes.  Resolving as fixed.

Sign in to add a comment