Re: [w3ctag/spec-reviews] WebVR (#106)

Taken up at our Tokyo face-to-face meeting.

Re: https://github.com/w3c/webvr/issues/128, we tend to agree that the pattern is not very "webby". As noted, the same amount of mem-copying is used in both approaches, but in the "new object" approach, you must additionally allocate a new var (at a minimum), and that's what I understand the concern to be (GC backpressure). @slightlyoff and I agree that it's a bit premature to be concerned about how much of a real-world problem this is without concrete implementation data, and so lacking that, we would be in favor of changing to a model that returns a new object instance each time.

As an alternative approach, the frame data could be considered a mutable state object, and you would use a singleton to store all the data (and to freshen the frame data within), and announce changes via events:
```js
partial interface VRDisplay {
   readonly attribute VRFrameData currentFrameData;
};
```
where the VRFrameData object has a `change` event. In this way you avoid allocated new objects each frame in a way that is more "webby". This is not prescriptive, just an alternate approach.

For the larger review, I haven't yet started it, but in discussion at our meeting, one concern raised was how much work would be required on the UI thread to achieve a 120Hz framerate, and whether it makes sense to require off-thread processing via off-screen Canvas.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/106#issuecomment-257493565