New issue
Advanced search Search tips

Issue 883366 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug
Proj-XR
Proj-XR-VR

Blocking:
issue 882618



Sign in to add a comment

WebVR hits NOTIMPLEMENTED in viz::DisplayScheduler::OnBeginFrameSourcePausedChanged

Project Member Reported by klausw@chromium.org, Sep 12

Issue description

Chrome Version: ToT
OS: Android

What steps will reproduce the problem?
(1) Enable WebVR in chrome://flags
(2) Go to https://webvr.info/samples/03-vr-presentation.html
(3) Tap "Enter VR"

What is the expected result?
What happens instead?

Log message after starting presentation:

[ERROR:display_scheduler.cc(306)] Not implemented reached in virtual void viz::DisplayScheduler::OnBeginFrameSourcePausedChanged(bool)


The code in question is here:

https://cs.chromium.org/chromium/src/components/viz/service/display/display_scheduler.cc?l=302&rcl=a7dd3bd6af99ee62527148d9dfdb9eef8ef2c404

void DisplayScheduler::OnBeginFrameSourcePausedChanged(bool paused) {
  // BeginFrameSources used with DisplayScheduler do not make use of this
  // feature.
  if (paused)
    NOTIMPLEMENTED();
}

The assumption in the comment does not appear to be true for VR, that does pause BeginFrame:

https://cs.chromium.org/search/?q=setVSyncPaused+file:java&type=cs

This is likely contributing to  issue 882618  where magic window rAF no longer fires after exiting presentation.

According to boliu@:

> if begin frame paused is never propagated to renderer, then renderer wrongly assumes more begin frames to come, and that can cause deadlocks in the renderer, it was with texture_layer too when I added begin frame paused, but I guess eric changed somethings there
> 
> sounds to be like should just implement that, shouldn't be too hard

boliu@ also said that this is also likely to cause issues with the new Viz Display Compositor (OOP-D) aka chrome://flags#enable-viz-display-compositor.
 
Blocking: 882618
Actually, probably should confirm if begin frame paused signal is never reaching renderer. I don't know the code for viz::Display well, and I'm not sure if DisplayScheduler or something else in display propagates the begin frame paused signal to renderer. I was just assuming it's the DisplayScheduler in the chat, but that's probably wrong..

Issue with oop-d is separate. VR pauses begin frame in WindowAndroid. With oop-d, WindowAndroid is no longer the begin frame source, so pausing WindowAndroid one does nothing.
I've attached a logfile. The "not implemented" message comes from PID 15642 which appears to be the GPU process, its TID 15676 doesn't appear elsewhere in the log.
logcat_org.chromium.chrome.browser.vr.VrBrowserTransitionTest.testWebVrReEntryFromVrBrowser_20180912T010207-UTC_FA6CG0305006.txt
551 KB View Download

Sign in to add a comment