Hi Jacob,
You are correct that timeStamp is the time at which the DOM event is
created. However, by my statement [1] I meant the hardware time (which on
most platforms is the time at which the system kernel received the event).
This is the systemTime for the event.
I'm not clear on what the behavior should be for events which do not result
from hardware. By leaving it undefined we could detect whether we know the
hardware time for an event, but defaulting to the event creation time would
allow comparing systemTime regardless of whether the event was hardware
generated or not. I could imagine trying to identify the time at which the
cause of the event occurred and use this as often as possible (i.e. time of
network packet arrival, script causing event, etc). I think always having a
systemTime would be ideal.
-Rob
[1] http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html
On Tue, Dec 18, 2012 at 1:14 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:
> Hey Rick,****
>
> ** **
>
> Looking at this issue [1], I agree that DOMHighResTimeStamp is probably
> the right units for this. ****
>
> ** **
>
> The important nuance to hwTimestamp is that it represents the time at
> which the **hardware** reported the event, not the time the event is
> dispatched. I believe timeStamp is the latter (Olli may correct me).
> Hardware times, as opposed to message times, let you calculate the time
> between two interactions (e.g. down, up) as opposed to the time between
> handling the events for the interactions. It’s a subtle difference, but on
> slower devices or sites with long running scripts it can make a difference.
> ****
>
> ** **
>
> I’m not sure if Rob meant hardware time or event handling time in his
> statement below:****
>
> “the monotonic system time responsible for the creation of the DOM event”
> [2]****
>
> ** **
>
> Since not all DOM events result from hardware, I’m not sure how we would
> define this globally (e.g. “systemTime” on Event).****
>
> ** **
>
> -Jacob**
>
> ** **
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20220****
>
> [2] http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html*
> ***
>
> [3] http://html5labs.interoperabilitybridges.com/dom4events/ ****
>