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

Re: [timingobject] Chaining timing objects

From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
Date: Fri, 28 Aug 2015 11:25:46 +0000
To: public-webtiming@w3.org
Message-ID: <issue_comment.created-135744512-1440761145-sysbot+gh@w3.org>
Sorry, forgot about that. 

Yes, it would work to generate new provider objects. But it is a bit 

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
Received on Friday, 28 August 2015 11:25:49 UTC

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