W3C home > Mailing lists > Public > public-device-apis-log@w3.org > February 2017

Re: [sensors] Provide the DeviceOrientation sensor

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
Message-ID: <issue_comment.created-283054356-1488292363-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:34:22 UTC