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

Received on Sunday, 27 November 2016 20:21:25 UTC