WebVR hits NOTIMPLEMENTED in viz::DisplayScheduler::OnBeginFrameSourcePausedChanged |
|
Issue descriptionChrome 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.
,
Sep 12
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.
,
Sep 12
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. |
|
►
Sign in to add a comment |
|
Comment 1 by klausw@chromium.org
, Sep 12