- From: Maksims Mihejevs <max@playcanvas.com>
- Date: Thu, 24 Nov 2016 18:11:04 +0000
- To: W3C Device APIs WG <public-device-apis@w3.org>
- Message-ID: <CAKLbJipZJL+7aOfaH+-ysM8hhg2VGOBaQ2gDQyDTfbB57HdvoA@mail.gmail.com>
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