Three.js: WebVR video texture frozen Chrome/Android

[eipporko]

Description of the problem

When I tried to use WebVR using a video as a texture mapped to geometry, the video in WebVR mode is frozen, but in the background the video seems to be playing, this only happens in Android devices. This also happens with the provided example (WebVR/video).

As soon as you click "ENTER VR" in Android the video gets frozen with the last frame showed before clicking.

https://threejs.org/examples/webvr_video.html

Three.js version

• [ ] Dev
• [x] r87
• [x] r88

Browser

• [] All of them
• [x] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [] All of them
• [ ] Windows
• [ ] macOS
• [ ] Linux
• [x] Android
• [ ] iOS

Hardware Requirements (graphics card, VR Device, ...)

Android mobile phone webvr compatible

[Mugen87]

I can confirm this bug on my Pixel.

[Mugen87]

I guess the problem is the usage of requestAnimationFrame in VideoTexture. When the VRdisplay is presenting, window.requestAnimationFrame does not fire but its respective counterpart.

[eipporko]

Opening the same example throw telegram or hangouts works.
When you open an hyperlink in one of this message clients, it's possible to view the webpage in a webview inside the program. It's very akward, because this webviews are dependant on the chrome installed into the device.

[mkeblx]

Some context here discussing window.requestAnimationFrame behavior when WebVR presenting, on mobile:
https://github.com/w3c/webvr/issues/225
https://bugs.chromium.org/p/chromium/issues/detail?id=712865

Can solve by modifying VideoTexture but need a nice way of getting access to the VR device object, currently reference found in WebGLRenderer. Maybe set a THREE.activeVRDevice and use everywhere?

[mkeblx]

Or a THREE.requestAnimationFrame() that is similarly made aware of current device and uses window or VRDisplay appropriately.

[mrdoob]

I guess the problem is the usage of requestAnimationFrame in VideoTexture. When the VRdisplay is presenting, window.requestAnimationFrame does not fire but its respective counterpart.

Oh noes... I guess we'll have to move that code to the renderer..

[Mugen87]

I guess we'll have to move that code to the renderer.

Okay, let's give it a try :blush: . I've made a PR that refactors the update according to your suggestion.