- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Sun, 23 Aug 2015 17:10:26 +0000
- To: public-webtiming@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