W3C home > Mailing lists > Public > public-device-apis-log@w3.org > May 2017

Re: [sensors] Define processing model

From: Alexander Shalamov via GitHub <sysbot+gh@w3.org>
Date: Wed, 24 May 2017 10:23:46 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-303682612-1495621424-sysbot+gh@w3.org>
> I think you're not taking into consideration the fact that in such scenarios, developers won't be relying on onchange events, but will instead simply get the value off of the corresponding attribute with each rAF. So the the speed at which an event is delivered in the meantime is irrelevant.

We take into consideration both facts, when data is read due to 'onchange' event or directly from rAF event handler. Both code paths should introduce as less latency as possible, therefore, it would be good to decouple 'onchange' from rAF.

> My question wasn't about this, however, but about whether this change in architecture implied a slower IPC solution to transfer the readings to the application layer which would increase latency.

In Chrome implementation, we use same shared memory IPC, no change to architecture at all.

> I think you're missing the point I'm trying to make here. I assumed (as that was the understanding shared by everyone here until a week ago) that rAF sync would mitigate jank issues by staying out of the rendering path. Now that I'm told rAF won't (or doesn't work for other reasons). The jank concern stays a concern until it is provably not so. OR are you suggesting @slightlyoff's concerns are just completely out of touch?

I just asked whether you know about other non-UI bound APIs that do rAF sync, maybe we can learn from them.

>Well, if you're polling at 1000 Hz and the web developer only uses 60 samples per seconds.

I think there was consensus that we are not delivering data faster than was requested by sensor instance.
High sampling rates not necessarily equal to same data rates, as I mentioned before, sensor can be running at 8kHz, while data is delivered at 60Hz, thus, we will only make 60 memcpy copies per second. If developer needs higher output data rate, higher 'frequency hint' can be provided (frequency hint is more or less ODR, in HW sensor terms).

GitHub Notification of comment by alexshalamov
Please view or discuss this issue at https://github.com/w3c/sensors/issues/198#issuecomment-303682612 using your GitHub account
Received on Wednesday, 24 May 2017 10:23:53 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:54 UTC