Re: Minimal event timing proposal

Regarding First Input Delay, we do lots of input latency measurements as
Blur Busters, albiet from other points of views (e.g. gaming latency).
Even 5ms makes a big difference in certain contexts.  Over the long term,
1000Hz mice should be streamed directly in an atomic manner to Javascript
-- instead of always permanently only coalesced into PointerEvents API.

Microsoft Resarch has found that realtime processing of 1000Hz input make a
huge difference:
https://www.youtube.com/watch?v=vOvQCPLkPt4

Even on a 60Hz display it can still have large benefits.

That said, understandably, while battery power can be a concern, Safari has
been limiting lots of processing to 60Hz even on the new 120Hz iPads,
certainly should be fleshed out better in all of this standardization
work.  Many things like requestAnimationFrame() in Safari only runs at
60fps even on the 120Hz iPads, even though Section 7.1.4.2 of HTML 5.2
recommends it running at full frame rates on higher-Hz displays (like in
other browsers, Chrome, FireFox, Opera, and even some versions of Edge).
 These add unwanted input lag to touchscreen events on Safari.   These are
major input lag considerations, adding +8ms of input lag to browser apps
rendered in <canvas> by running rAF() at 60fps instead of 120fps on the
120Hz iPads.   The display-side equation is part of the lag arithmetic too,
even though there are also power-consumption-versus-lag tradeoffs.


On Mon, Mar 26, 2018 at 4:26 PM, Timothy Dresser <tdresser@chromium.org>
wrote:

> I've updated the proposal on WICG here
> <https://github.com/WICG/event-timing/blob/master/README.md>.
> This proposal requires only dispatching PerformanceEventTiming entries if
> the duration between event startTime and when event processing is finished
> is > 50ms.
>
> Tim
>
> On Fri, Feb 16, 2018 at 1:43 PM Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> Tim, thanks for drafting this! I like where this is headed.
>>
>> Left a few questions in the doc and added this to our agenda for next
>> design call
>> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.ljsbtcikd3cl> (date
>> TBD).
>>
>> On Thu, Feb 15, 2018 at 1:53 PM, Timothy Dresser <tdresser@chromium.org>
>> wrote:
>>
>>> Based on our discussion on First Input Delay
>>> <https://docs.google.com/document/d/1Tnobrn4I8ObzreIztfah_BYnDkbx3_ZfJV5gj2nrYnY/edit> at
>>> the last WG meeting, I've put together a minimal proposal
>>> <https://docs.google.com/document/d/10CdRCrUQzQF1sk8uHmhEPG7F_jcZ2S3l9Zm40lp3qYk/edit#heading=h.fbdd8nwxr7v4> for
>>> an event timing API.
>>>
>>> The extensions to the DOM spec are fairly straight forward, and the API
>>> itself is pretty bare bones. The main question is whether or not
>>> dispatching an entry per DOM event is too expensive.
>>>
>>> If it is, we'll need to devise a method to only report a subset of
>>> events.
>>>
>>> I'd appreciate any feedback you have,
>>> Tim
>>>
>>
>>