- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Feb 2017 14:32:45 +0000
- To: public-device-apis-log@w3.org
Sorry, playing devils advocate here, but we want this to be solid: > avoid unnecessary object construction and wrapping of objects -> performance/memory overhead Not sure why you'd need to wrap stuff? Can you be more specific? Also, afaik, constructing regular arrays is cheaper than Typed ones. > matrices/vectors etc are basically array formed data, and methods working on them, can all be adopted to work on arrays directly in a straight forward manner (matrices are laid out per row - only requirement). Sure, but this comes with extra GC issues which don't exist otherwise and which need to be handled via BYOB-type APIs which aren't exactly trivial. There's seems to be multiple different ways to represent matrices using (typed|regular) arrays (including nested structures). Which ones should we pick and why. Where are they specified it at all. > That is not the case for specific objects, where they must know the specifics of the object, like property names. The rest of the platform considers that to be a feature. Why is this not the case here? :P > arrays can be modified easier by external tools, such as SIMD.js and Web Assembly. I don't really think we can make the case for working well with certain JS libs as a Web standard. With Web Assembly perhaps a bit more so. Can you explain precisely how this WA-based modification would work? -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/170#issuecomment-283054356 using your GitHub account
Received on Tuesday, 28 February 2017 14:32:51 UTC