- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Sun, 18 Dec 2016 11:04:56 +0000
- To: public-device-apis-log@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. That doesn't bother me, frankly. If you have options that change the behavior of the sensor, it seems appropriate that those would be reflected on the data. My feeling is that for the case where this will really become an issue, the right answer is probably to create different interfaces altogether. > - `snapshot()` makes new object, I don’t see any difference to what we have at the moment. Yeah. That was for the case where a snapshot *is* needed. E.g. for storing readings. @rwaldron indicates above that ES6 syntactic sugar makes that redundant, though. So let's drop it. > - `timeStamp` is only accessible through `snapshot()` => for algorithms that use timestamp, performance would be the same as with the current API. You're right. This belongs on the main API too. Need to find a better name for it, though. > 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. I don't think there's any doubt that GC pauses is a serious issue for high perf real-time use-cases. This has been the case for a decade in the Web, is one of the motivations behind ASM.js and WASM (or however that thing is called nowadays), and is the reason game developers usually pool resources on GC platforms. That said, more perf tests is always a good thing. In order to measure the impact of GC on perf, I suggest looking at impact on a real game on low-end devices. Maybe you could look at something like this gamebench: http://www.scirra.com/demos/c2/sbperftest/ and see how it fares on a low end Android device once you add 120 new gyroscope objects per second and whatever the max polling rate for magnetometer is. > 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. Yeah, I'm not hostile to the "bring your own buffer" design pattern. iirc WebCrypto uses it quite a bit. It's a lot less user-friendly though, so it needs to have serious benefits beyond theoretical purity (we can't dismiss [priority of constituencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies)). -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/153#issuecomment-267815140 using your GitHub account
Received on Sunday, 18 December 2016 11:05:02 UTC