Re: [sensors] Don't allocate response objects to avoid triggering GC

> But if there is no object involved, such as sensor.x, then:
> ...
> There is much less chance to get confused in this case.

Yep, that's how J5 is designed as well. 

--------------


I've never been a fan of the `sensor.reading.foo` design, but was 
always willing to accept that certain changes would need to be made to
 accomodate the platform. I'm happy to see that we're circling back 
before fully committing to the existing design. 

The design that @tobie suggested above, which had this example: 

```js
let gyro = new Gyroscope({ frequency: 240 });
gyro.start();
    
gyro.onchange = _ => {
    console.log("Rotation rate around the X-axis " + gyro.x);
    console.log("Rotation rate around the Y-axis " + gyro.y);
    console.log("Rotation rate around the Z-axis " + gyro.z);
};

gyro.onerror = event => console.log(event.error.name, 
event.error.message);
```

Satisfies criteria 1, 2 and 3. Here's how: 

> 1. high-frequency low-latency use-cases (e.g. head-tracking for VR),

We already know why, it's because there is no excessive allocation and
 therefore no excessive GC demands.

> 2. operating over multiple, sequential sensor readings in (near-) 
realtime (e.g. Kalman filters),
> 3. storing sensor reading for further processing at a later stage, 
either locally or remotely.

Application code can easily copy the values from the properties and 
store them for later, if they want to do so:  

```js
let cache = [];
gyro.onchange = _ => {
    cache.push({ x, y, z } = gyro);
};
```

... Any amount of historic data can be kept or discarded as needed by 
the application (re: criteria 2)






-- 
GitHub Notification of comment by rwaldron
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/153#issuecomment-265570801 using
 your GitHub account

Received on Wednesday, 7 December 2016 20:56:37 UTC