W3C home > Mailing lists > Public > www-svg@w3.org > September 2003

RE: animations and intervals

From: Patrick Schmitz <cogit@ludicrum.org>
Date: Tue, 2 Sep 2003 11:19:14 -0700
To: "Sigurd Lerstad" <sigler@bredband.no>, <www-svg@w3.org>, <www-smil@w3.org>
Message-ID: <ENEGINNFOHPGHPIICCFJKECHDKAA.cogit@ludicrum.org>

Yes. Until you are reset (as described in the spec), I recommend you keep
all the intervals so that you can correctly handle the case of hyperlink
navigation to an earlier point in time.  When you are reset (e.g. when your
parent repeats), it is reasonable to discard the historical intervals.
Naturally, this means that there are limits to repeatability when seeking
backwards.

Patrick

> -----Original Message-----
> From: Sigurd Lerstad [mailto:sigler@bredband.no]
> Sent: Tuesday, September 02, 2003 5:25 AM
> To: cogit@ludicrum.org; www-svg@w3.org; www-smil@w3.org
> Subject: Re: animations and intervals
>
>
> Hello,
>
> a long time since I asked this, but I haven't worked on it since so...
>
> I just need a simple clarification.
>
> You are talking about intervals and not the instance time lists?
> The spec is
> pretty clear about how to handle those.
>
> thanks again,
>
> --
> Sigurd Lerstad
>
> >
> > Hi -
> >
> > I will jump in since I worked on the SMIL Timing stuff. Yes, you should
> keep
> > a list of historical intervals until you are reset (assuming you support
> > time containment at some point).  Hyperlink navigation is an entirely
> valid
> > means of interaction and should not be dismissed as "just seeking".  The
> > ability to seek backwards can be crucial to authors in some cases, and
> this
> > is why it was specifically included in SMIL 2 timing. The combination of
> > hyperlinking and indeterminate timing (e.g. event based timing) is
> somewhat
> > complex, but it is consistent. For the SVG 1 case without time
> containers,
> > it is actually fairly simple.
> >
> > Climbing out on a limb, I will comment that if you are considering not
> > keeping the historical intervals, you may be treading close to some more
> > serious problems in the implementation. If you are just considering a
> minor
> > optimization to toss out a few small objects, fine. If you are
> considering
> > departing from the model described in the spec, you are likely
> headed for
> > trouble.
> >
> > If you have other questions about the SMIL timing model, I
> would happy to
> > help clarify the spec. I know it is not entirely obvious - it is a spec
> and
> > not a tutorial. In some places, we attempted to clarify
> precisely what we
> > meant, but the detail can be bewildering on the first read.
> >
> > Good luck with it - Patrick
> >
> > > -----Original Message-----
> > > From: www-smil-request@w3.org
> [mailto:www-smil-request@w3.org]On Behalf
> > > Of Sigurd Lerstad
> > > Sent: Tuesday, April 29, 2003 1:14 AM
> > > To: www-svg@w3.org; www-smil@w3.org
> > > Subject: animations and intervals
> > >
> > >
> > >
> > > Hello,
> > >
> > > Reading up on intervals and current interval etc. in the SMIL
> > > timing model.
> > >
> > > Is it a good idea to keep a history of all the intervals
> created for an
> > > animation element? I'm looking into seeking backwards, and
> > > though the rules are not completely clear to me yet, is keeping a list
> of
> > > already happened intervals a good idea (or even necessery) to
> > > seek backwards? It is my understanding that this is not necessary when
> > > playing normally and when seeking forwards.
> > >
> > > As Thomas E Deweese said, it's a good thing to refer to the specs
> > > and saying
> > > why I think the spec isn't clear when asking a question, however, all
> this
> > > is very fuzzy at the moment, and I don't have a complete understanding
> of
> > > the spec yet, I'm simply asking for implementation advise on
> > > wether keeping
> > > a list of history intervals for the sake of seeking backwards is
> > > a good idea
> > > or not, a simple yes or no from someone with implementation
> > > experience will
> > > do, so I know I'm on the right track.
> > >
> > > thanks,
> > >
> > > --
> > > Sigurd Lerstad
> > >
> >
> >
>
>
Received on Tuesday, 2 September 2003 14:20:43 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:25 GMT