Re: [timingobject] Is timeupdate event necessary?

In regards to 2), why would time update be chained?  I presume the code in
1) or equivalent could easily be included into the timing object itself, so
nodes generate timeupdate events on subscriptions.  They are not inherited,
hence there is no need for a transformation.  The timeupdate event is very
convenient, if only to limit the amount of cut'n'paste code that people get
wrong.

---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 23 August 2015 at 19:10, Ingar Arntzen via GitHub <sysbot+gh@w3.org>
wrote:

> ingararntzen has just created a new issue for
> https://github.com/webtiming/timingobject:
>
> == Is timeupdate event necessary? ==
> We have discussed this one before on the mail list here [1], here [2]
> and here [3].
>
> Basically the argument is that it's not strictly necessary, but that
> it may be practical in many circumstances.
>
> I just wanted to raise this as an issue on GitHub since it is
> currently included in the spec under development.
>
> Also, I wanted to add two more considerations.
>
> 1) The practical benefit could also be secured without it being part
> of the spec, for instance by providing a simple utility function that
> adds periodic callback functionality to a timing object when you need
> it.
>
> Code example below shows how to set up a periodic callback which does
> not fire when the timing object isn't moving.
> ```js
> var setIntervalCallback = function (timingobject, handler,
> intervalMillis) {
>         var tid = null; // timeout id
>         timingobject.on("change", function (e) {
>                 // always fire timeupdate after change event
>                 handler();
>                 // start or stop periodic timer
>                 var v = timingobject.query();
>                 var isMoving = (v.velocity !== 0.0 || v.acceleration
> !== 0.0);
>             if (isMoving && tid === null) {
>                 tid = setInterval(function() {
>                         handler();
>                 }, intervalMillis);
>         } else if (!isMoving && tid !== null) {
>                 clearTimeout(tid);
>                 tid = null;
>         }
>         });
> };
> ```
>
> 2) Having started to look into chaining a bit (see Issues [4]) I've
> noted that wrapping a timingobject (in order to implement some
> transformation of the underlying motion) gets slightly more
> complicated with the timeupdate, and also add the potential for errors
>  if the programmer forgets to apply the transformation to the
> timeupdate event. Also, lots of events will have to be generated even
> if no-one needs them. This is because only the last object in the
> chain knows if there is an actual subscriber to the event (unless this
>  is to be propagated up-chain making the implementation even more
> complicated).
>
> So, with this I'm still in favor of dropping the timeupdate event from
>  the spec.
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-webtiming/2015Jun/0002.html
>
> [2]
> http://lists.w3.org/Archives/Public/public-webtiming/2015Jun/0003.html
> [3]
> http://lists.w3.org/Archives/Public/public-webtiming/2015Jun/0004.html
> [4] https://github.com/webtiming/timingobject/issues/13
>
> See https://github.com/webtiming/timingobject/issues/15
>
>