W3C home > Mailing lists > Public > public-webtiming@w3.org > August 2015

[timingobject] Is timeupdate event necessary?

From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
Date: Sun, 23 Aug 2015 17:10:26 +0000
To: public-webtiming@w3.org
Message-ID: <issues.opened-102638817-1440349826-sysbot+gh@w3.org>
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
Received on Sunday, 23 August 2015 17:10:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC