googlearchive / vrview

Library for embedding immersive media into traditional websites.
http://developers.google.com/cardboard/vrview
Apache License 2.0
1.71k stars 1.09k forks source link

[Performance] Multiple vrview players on the same page. #239

Open andrebonon opened 7 years ago

andrebonon commented 7 years ago

Hi Guys,

I'm facing some performance issues when I have multiple vrview players on the same page. On iPad for example, when I have more than 4 vr players on the same page, it makes the page reloads every time.

Using the javascript profiler I could identify that the loop function uses a lot of memory, so I was wondering to cancel the animation frame for the VRDisplay loop function. ( window.cancelAnimationFrame() ) What do you think?

To do that, I need to store and expose some values like the id that window.requestAnimationFrame() provides and the loop function itself.

On the piece of the code below, I'm storing the id and the loop function on the public VRDisplay object.

function loop(time) {
  // Use the VRDisplay RAF if it is present.
  if (worldRenderer.vrDisplay) {
-    worldRenderer.vrDisplay.requestAnimationFrame(loop);
+    worldRenderer.vrDisplay.loopRequest = worldRenderer.vrDisplay.requestAnimationFrame(loop);
+    worldRenderer.vrDisplay.loopCallback = loop;
  }

Can I send pull request?

Besides, I have a feature suggestion. What do you think to cancel the requestAnimationFrame() if the VRVIEW Player is not visible? It also can save some memory and get better the performance.

lincolnfrog commented 7 years ago

I am open to this change. Go ahead and make a PR and I'll review it / work with you to get it submitted.

Our general philosophy about changes is to make sure we preserve backwards compatibility with the existing functionality. We don't want to break anyone's sites that use vrview. If you can engineer this in a way to hide the changes behind a flag or use an optional parameter to requestAnimationFrame such that old calls behave the same, then I will support the change.

As for canceling if the player isn't visible, I think that is reasonable but we need to iron out the details. Does it start processing again when it comes back on screen? Does this mean if someone is watching a video with sound, like the Apes example, and then scrolls down that the video pauses and they can't hear it anymore. Is that right? It might be nice for it to work like YouTube where you can still listen to videos even if they are not visible.

Those are my initial thoughts and concerns, let me know if you have any responses and I say go ahead with a PR.

andrebonon commented 7 years ago

Awesome to hear that. In my tests, when I canceled the requestAnimationFrame() by using cancelAnimationFrame(id), I was still listening to the audio while the image and drag&drop were frozen. When I called the requestAnimationFrame(loop) function, I could see the video not frozen anymore, it was playing normal.

So, the main idea will check if the player isn't into the view or display:none, so then we can cancel the loop function until the user scrolls to that.( check in viewport ) Does it meet your expectations? Does it make sense?

lincolnfrog commented 6 years ago

@andrebonon hey, sorry for not responding. Yes, that plan sounds good. Go ahead and make a PR if you don't mind!