Garbage collection and compilation operations can cause hard to predict, noticeable slowdowns for large real-time JS apps so I'm skeptical of the use for ReactVR right now. Perhaps I'm wrong though? Or maybe it will be useful for static, UI scenes?
The React team has been working on an improved rendering engine called Fiber. This is an oversimplification but Fiber essentially breaks down per-frame rendering into several sub rendering tasks, allowing for smarter multi-threading (in the case of web workers) and even single threading (the renderer now returns control of the main thread much faster and more frequently, allowing for more opportunities to do GC and other operations without as much of a negative effect.)
What this amounts to for React developers is the introduction of explicit priority rendering, which can be very useful in VR environments. So for example, updates to your UI from external processes (such as an XHR) can be set to lower priority than updates to the hand model that's controlled by the controllers.
I think maybe the basic idea is that by utilizing more cores and getting more done concurrently, they leave more idle time per frame for the GC to work. If that's the case, it doesn't necessarily solve the problem, but it may move the bar enough to be currently usable and useful.
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.
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.
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.
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.
Somebody convince me!