W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2012

Re: DOMHighResTimeStamps in DOM events, use cases

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 4 Jun 2012 09:34:16 -0500
Message-ID: <CABirCh-H5k8PRgZ6YFZ7p4Po4MTVOpSaame3XdyEOQOFPd42_Q@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Pablo Garaizar Sagarminaga <garaizar@deusto.es>, www-dom@w3.org
On Mon, Jun 4, 2012 at 2:23 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> #4 Accurate responses in games. For example in a rock-band style game,
> the user attempts to hit the key exactly at a specific time.
>

I've worked on rhythm games, and we did indeed run input in a thread with
high-resolution timestamps on the input; in ideal cases this gave us
(empirically measured) input timing accuracy of under 1ms, which mattered a
lot.


> #5 Fluid behavior for animations. If an animation is started in
> response to a user event, but the main thread happens to be busy when
> the event should fire, the page can account for this and place
> animated items where they would be as if the animation had started
> exactly when the user event occurred.
>

Actually, for this one you don't want to do that.  If you process the
animation at 1.0s, and the user input happened at 0.0s (exaggerated), then
the animation will visibly skip forward by one second.  Usually it's much
better to let the animation be a little delayed than to have it jump
forward to catch up.

(I hit this problem a lot when working on game animations: we always had to
be sure to flush timers to make sure animations don't jump ahead in cases
like this.)

-- 
 Glenn Maynard
Received on Monday, 4 June 2012 14:44:18 GMT

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