3 ms·
Events are useless for this. When you execute a function with requestAnimationFrame, it runs after the frame is drawn so it has enough time to prepare and rende
by DiThi 12y ago
Events are useless for this. When you execute a function with requestAnimationFrame, it runs after the frame is drawn so it has enough time to prepare and render everything before the next frame is drawn. You can then calculate and render everything that is not VR-motion dependant, then query the device and finally draw it. From a latency perspective it makes sense that the code can poll the data and the browser can manage the deform (but IMHO it shouldn't be mandatory).
> The most significant idea here, it seems, is rendering DOM to a 3D texture.
Where is that mentioned?
- Tojiro 12y agoHe's referring to techniques mentioned by Vlad's blog post about Mozilla's WebVR implementation, which was linked by this post. (Vlad's post is here - http://blog.bitops.com/blog/2014/06/26/first-steps-for-vr-on-the-web/ http://blog.bitops.com/blog/2014/06/26/first-steps-for-vr-on...) Chrome is actually going to steer clear of VR+DOM until Mozilla has a working prototype.
- newhouseb 12y agoThat's a good point, pull is nice. You could also run the push events at a higher frequency too (I think ondevicemotion events typically run at 20Hz, which is abysmal). My larger point is that if possible we should update the existing standard to provide push and pull from the same interface/abstraction, and that it shouldn't be limited to VR.