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: Wed, 07 Dec 2016 08:37:23 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-265387978-1481099841-sysbot+gh@w3.org>
Thanks for your input @alexshalamov. Getting back to our requirements,
 I think we want to try and fulfill the following, somewhat 
contradictory use-cases:

1. high-frequency low-latency use-cases (e.g. head-tracking for VR),
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.

Requirement 1) is extremely perf sensitive, and if our ability to 
deliver on it is hindered because we're triggering too much GC, we 
should definitely fix that. Requirements 2) and 3) on the other hand 
require that we have distinct objects representing each readings 
(additionally, timestamps for 3) need to have an epoch-based component
 and not be DOMHighResolution only).

The design I'm suggesting here (which, btw, is *just* a suggestion), 
delivers on 1), but require an extra bit of work for 2) and 3); 
basically a way to snapshot the state of the sensor at t<sub>n</sub>. 
I added a serializer in the above example as a placeholder. But that 
could also be a method, e.g.:

interface Sensor : EventTarget {
  readonly attribute SensorState state;
  void start();
  void stop();
  SensorReading snapshot();
  attribute EventHandler onchange;
  attribute EventHandler onactivate;
  attribute EventHandler onerror;

interface SensorReading {
  readonly attribute DOMHighResTimeStamp timeStamp;
  readonly attribute DOMHighResTimeStamp timeOrigin;

dictionary SensorOptions {
  double? frequency;

// E.g. for Gyroscope

interface GyroscopeValues {
  readonly attribute unrestricted double? x;
  readonly attribute unrestricted double? y;
  readonly attribute unrestricted double? z;

[Constructor(SensorOptions options)]
interface Gyroscope : Sensor {};
Gyroscope implements GyroscopeValues;

interface GyroscopeReading : SensorReading {};
GyroscopeReading implements GyroscopeValues;

We could even imagine building on top of this a buffer for all 
snapshots in between to event turns or some such.

GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/153#issuecomment-265387978 using
 your GitHub account
Received on Wednesday, 7 December 2016 08:37:29 UTC

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