W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2010

Re: Event.timeStamp

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 18 Oct 2010 20:47:02 -0700
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: www-dom@w3.org
Message-ID: <20101019034702.GA22091@pickering.dbaron.org>
On Monday 2010-10-18 22:47 -0400, Boris Zbarsky wrote:
> On 10/18/10 10:41 PM, Cameron McCormack wrote:
> >I also think we should make Event.timeStamp be not the time at which the
> >event was created (the construction of the Event object?) but the time
> >at which the event represented by the Event object occurred.
> 
> This is particularly relevant to situations in which the event is
> _about_ to occur and the UA wants to notify scripts of this.  While
> it can only guess at when the event will really occur (since the
> scripts could take a while), that still seems more useful than
> reporting some time in the past that has nothing to do with the
> event in question.
> 
> We (Mozilla) actually ran into this with MozBeforePaint events.  For
> now we're having the timeStamp on those represent the time when the
> paint is conceptually happening (i.e. the sampling time that will be
> used for animations when the paint happens).

Speaking of which, I'm actually not crazy about event.timeStamp
being in milliseconds since the Epoch.  The times that operating
systems report on events (like key events and mouse events) are, for
at least some systems, I think, based on an interval timer -- a
separate timer from the clock.  (I think (hope) that it's not
particularly related to the clock, and doesn't, for example, go
backwards if the clock is changed or adjusted by NTP.  I don't
really know the details.  At the very least, events from GDK are
documented to be in milliseconds (and are), and definitely aren't in
milliseconds since the epoch; those are the values that Gecko on
Linux reports for timeStamp.)

I think interval timer times are quite useful.  I'd like to be able
to have APIs that let Web pages do things like start animations
based on the time of the mouse or key event that triggered them,
which I think should make them appear more responsive, even if it
really takes them a little time to get started.

If we have to report a time in milliseconds since the epoch, we'd be
unlikely to be able to correctly report the time the key was
pressed; we'd have to report the time Gecko processed the key event,
which might be a bit later.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Tuesday, 19 October 2010 03:47:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:06 GMT