5 ms·

This seems like a good start but I'm a little worried about over-abstraction here, that is to say: baking a lot of design assumptions into the browser that real

This seems like a good start but I'm a little worried about over-abstraction here, that is to say: baking a lot of design assumptions into the browser that really should rely on user-level libraries. A lot of this can already be done with WebGL and .ondevicemotion events (See some of the cardboard demos). The most significant idea here, it seems, is rendering DOM to a 3D texture. There are some security issues here (we'd likely have to restrict rendering to resource on the same domain), but man, this would be a huge boon to many applications that are 3D and still need sensible Text layout.

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 ago
  He'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 ago
  That'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.

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 ago
He'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 ago
That'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.