3 ms·

I can't speak to ReactVR specifically, but if you've tried and profiled WebVR you realize that it (surprisingly) works in practice. It's actually not hard to f

by avaer 10y ago

I can't speak to ReactVR specifically, but if you've tried and profiled WebVR you realize that it (surprisingly) works in practice. It's actually not hard to finish executing your Javascript in 11 milliseconds (90 FPS) if you avoid the well-known, profilable tripping hazards such as not blocking on the DOM. 11ms is an eternity in CPU time if you're not running some big-N synchronous algorithm (which you should be doing in a worker), so most of this time is not even going to be spent in your Javascript: it's going to be in blocking GPU drawcalls and uploads, which can be executed in parallel with the garbage collector. So although it intuitively _seems_ Javascript VR would be killed by garbage collection, you can actually spend a large proportion of your time in garbage collection for free. And it works for much more than static scenes. You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery.

agd 10y ago
The reason I asked is because I've worked on several large commercial 3D WebGL games which ran into the issues I described. Yes you can get a complex game running at <=16ms per frame, but GC and compiler operations make it hard to achieve consistently smooth performance. This is even more noticeable in VR. > You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery. No. If you create large scale real-time JS apps, you will soon run into the issues I described.
- avaer 10y ago
  Scale is a very wishy-washy term. You can build complex applications with JS, you just need to move the scale out of the main loop. Don't run business logic alongside your render, or else you will indeed run into these problems. This advice isn't unique to Javascript and goes back to Carmack hacking on Doom, Wolfenstein 3D, and beyond. It's just that Javascript makes it easy to shoot yourself in the foot here, because this isn't a role that was forseen when JS was designed. Do you have any links to share? I'd love to learn more about these performance problems you describe.
- moron4hire 10y ago
  > This is even more noticeable in VR. No, it will be less noticeable in VR, because of asynchronous reprojection.
  - meheleventyone 10y ago
    On platforms that support it, depending on how big the GC stalls are (extrapolation isn't magic) and it's not really something you should be triggering regularly by design. Async reprojection was invented to mitigate the fact that a variable frame rate makes you sick in VR so really it's evidence to support the parents case. If you're regularly dipping into async reprojection due to the GC then a trade off between visual accuracy/artifacts and the GC is being made.

by avaer 10y ago

agd 10y ago

The reason I asked is because I've worked on several large commercial 3D WebGL games which ran into the issues I described. Yes you can get a complex game running at <=16ms per frame, but GC and compiler operations make it hard to achieve consistently smooth performance. This is even more noticeable in VR. > You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery. No. If you create large scale real-time JS apps, you will soon run into the issues I described.

avaer 10y ago
Scale is a very wishy-washy term. You can build complex applications with JS, you just need to move the scale out of the main loop. Don't run business logic alongside your render, or else you will indeed run into these problems. This advice isn't unique to Javascript and goes back to Carmack hacking on Doom, Wolfenstein 3D, and beyond. It's just that Javascript makes it easy to shoot yourself in the foot here, because this isn't a role that was forseen when JS was designed. Do you have any links to share? I'd love to learn more about these performance problems you describe.
moron4hire 10y ago
> This is even more noticeable in VR. No, it will be less noticeable in VR, because of asynchronous reprojection.
- meheleventyone 10y ago
  On platforms that support it, depending on how big the GC stalls are (extrapolation isn't magic) and it's not really something you should be triggering regularly by design. Async reprojection was invented to mitigate the fact that a variable frame rate makes you sick in VR so really it's evidence to support the parents case. If you're regularly dipping into async reprojection due to the GC then a trade off between visual accuracy/artifacts and the GC is being made.