- From: Travis Leithead <notifications@github.com>
- Date: Mon, 31 Oct 2016 22:45:15 -0700
- To: w3ctag/spec-reviews <spec-reviews@noreply.github.com>
- Message-ID: <w3ctag/spec-reviews/issues/106/257493565@github.com>
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
Received on Tuesday, 1 November 2016 05:45:49 UTC