- 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