W3C home > Mailing lists > Public > public-device-apis-log@w3.org > December 2016

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

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Tue, 06 Dec 2016 11:51:26 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-265131404-1481025085-sysbot+gh@w3.org>
The original API design as proposed by @rwaldron didn't have GC 
collection issues. The new design does, mainly because I wanted the 
same API to be available from the event object and the sensor instance
 itself.

Now that we've stopped exposing the sensor reading from the event 
object, maybe we should reconsider exposing it as a separate object on
 the sensor itself to avoid GC issues.

What if we tried something like that instead (here for gyroscope)?:

```webidl
[SecureContext]
interface Sensor : EventTarget {
  readonly attribute SensorState state;
  readonly attribute DOMHighResTimeStamp timestamp;
  void start();
  void stop();
  attribute EventHandler onchange;
  attribute EventHandler onactivate;
  attribute EventHandler onerror;
};

dictionary SensorOptions {
  double? frequency;
};

[Constructor(SensorOptions options)]
interface Gyroscope : Sensor {
  serializer = { x, y, z, timestamp }; // so we can still get a 
reading object when needed
  readonly attribute unrestricted double? x;
  readonly attribute unrestricted double? y;
  readonly attribute unrestricted double? z;
};
```

That would allow uses like this:

```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)
```

Thoughts? 

-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/153#issuecomment-265131404 using
 your GitHub account
Received on Tuesday, 6 December 2016 11:51:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:52 UTC