This is pretty exciting stuff. Several months ago I had made a Chrome packaged app that used Chrome's USB API to get Rift orientation data ( https://github.com/DanAndersen/cupola ), but it's good to see work being done to integrate it into the browser itself instead of the hackish way I had to go about it.
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.
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.
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.
