RE: Sensors API - GC and Real-Time performance considerations.

Hi Maksims,

Thank you for your very valuable input!

Tobie (in CC) can probably reply better about all guidelines and priorities that drive the Generic Sensor API, however high performance in fetching sensor data as well as reliable data timing are definitely in a high priority for us.

As for the Generic Sensor API implementation in Chromium, it uses a shared memory buffer to provide sensor data from platform to JS engine in the fastest way possible (the sensor data is fetched from the platform and put to the shared buffer considering the given frequency hint (https://w3c.github.io/sensors/#dictdef-sensoroptions)).

Besides, every sensor reading has a high resolution timestamp of the time at which the reading was obtained (https://w3c.github.io/sensors/#sensorreading), so that it should be easy to synchronize sensor input with other events.

Please let us know if you have further questions, also you can create issues for the Generic Sensor specification and file bugs for the implementation in Chromium.

Thanks,
Mikhail

From: Maksims Mihejevs [mailto:max@playcanvas.com]
Sent: Thursday, November 24, 2016 8:11 PM
To: W3C Device APIs WG <public-device-apis@w3.org>
Subject: Sensors API - GC and Real-Time performance considerations.

Hello.

I've been watching development process and discussions regarding Sensor API for some time now, and have few concerns.
Coming from WebGL/WebVR and real-time applications area, many of users within that area have to access and communicate to sensors in fast and efficient way.
Where applications are targeting 60fps, and even higher in the future with VR requirements, it is very important that those APIs are real-time friendly.


Garbage Collection - one of the major bottlenecks and high consideration for real-time applications. If application is targeting 60+ fps, it has to avoid any allocations and avoid calling any native JS methods that allocate response objects, for example getBoundingClientRect.
High GC loops do lead to periodical JS thread stalls, that can drop many frames, making 60fps unreachable.

State / Async - in real-time nature of development, async code does not fit fixed update loop paradigm. Where application is targeting to get fixed FPS (30/60), it requires to have access to data in that update method, most of the time it is within requestAnimationFrame. So for example when mouse interaction is required, due to old design of mouse API, developers require to subscribe to mouse events, and then store mouse coordinates in accessible scope, so then within update method they can access mouse data. This creates big mess when there are many things needs to be subscribed: orientation, VRDisplay pulling, window resizing/orientation, keyboard states, motion, touch, gamepads, and many-many others.
APIs that allow simply accessing latest state of whatever sensor or data it is - are way, way easier to use, and do not require too much of thinking about events, callbacks, etc.

Promises - as history shows, they are getting obsolete as ES6/7 solves much better what promises promised to solve - callback hell (which is doesn't solve). More to say: they are extremely bad for GC, as they do allocate a state data internally, passing objects around, as well as enforce function allocations, and lead to huge overload with unnecessary function scopes > complicates GC. Debugging is not good as well.


So my question:
1. What are the guidelines this APIs are designed by?
2. If GC is high consideration?
3. What are the highest priorities that drive the APIs design?
4. What are User Stories this APIs are engaged against in design process?


Looking forward to hear from you guys, and collaborate on making design to be a good fit for everyone, including real-time applications.

Kind Regards,
Max
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.