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: Alexander Shalamov via GitHub <sysbot+gh@w3.org>
Date: Fri, 16 Dec 2016 17:44:26 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-267652624-1481910264-sysbot+gh@w3.org>
@tobie There are few concerns with proposed modifications.

- When control and data interfaces are merged, extensibility is lost. 
For example, for sensors that can provide additional data in 
'uncalibrated / raw mode' either new interface should be created, or 
all possible data fields have to be present on main interface.

- `snapshot()` makes new object, I don’t see any difference to what we
 have at the moment.

- `timeStamp` is only accessible through `snapshot()` => for 
algorithms that use timestamp, performance would be the same as with 
the current API.

Chrome canary has implementation of ambient light, accelerometer, 
gyroscope and magnetometer. It would be good to have measurements that
 prove that the current approach would not allow us to reach 
continuous 60fps target. If required, I can quickly prototype infinite
 scroller with recyclable elements, so that we will see whether 
current approach affecting scrolling performance / fps or not.

If you still think that GC would be a problem, we could consider an 
alternative solution. Could we instead provide a method that will fill
 sensor reading data, e.g. `Sensor.getReading(Dictionary out);` or 
`Sensor.read(Dictionary out);`? This will allow to reuse object, yet, 
main interface is not polluted with unwanted fields and extensibility 
is not lost.

GitHub Notification of comment by alexshalamov
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/153#issuecomment-267652624 using
 your GitHub account
Received on Friday, 16 December 2016 17:44:37 UTC

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