- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Aug 2015 11:25:46 +0000
- To: public-webtiming@w3.org
Sorry, forgot about that. Yes, it would work to generate new provider objects. But it is a bit cumbersome. So this perhaps indicates the need for a set of predefined TimingWrapperObject (platform objects) ? I have a few in mind - shiftTimeline - shifts the timeline for the timing object (skew position of source timeline) - scaleTimeline - stretches the timeline of the timing object (beat/min - frame/sec) - loopTimeline - make a new timeline that is looped (modulo position of source timeline) - - rangeTimeline - add say range restrictions to a timing object that does not have range Though these will probably cover many use cases I doubt that they are exhaustive (what about Timingobject that represents the derivative of the motion of its source TimingObject?) It would be nice to be able to produce these in JS though. There is one other approach though... Lets say that we have two kinds of TimingObjects - one platform object and one user object. Lets call the latter say a MotionObject. Then we have the following chain Timing Provider -> Motion Object -> Timing Object -> Media Element The two first are JS and the role of the Timing Object is here to bring external motion from user space into platform space - making it available for all things built-in (media element, possibly sequencer, animation framworks, web audio etc). However, JS wrappers can now be applied on the Motion Object instead of the Timing Object. The TimingObject is more like a leaf node - and does not support wrapping/chaining. If you have developed some timing sensitive JS component I suppose you could hook it up to the Motion Object directly and not bother with the Timing Object at all? What about it? Too much? -- GitHub Notif of comment by ingararntzen See https://github.com/webtiming/timingobject/issues/13#issuecomment-135744512
Received on Friday, 28 August 2015 11:25:49 UTC