W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: Question about animate-elem-201-t

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Wed, 9 Jul 2008 19:30:22 +0200
To: www-svg@w3.org, Julien.Reichel@spinetix.com
Message-Id: <200807091930.23482.Dr.O.Hoffmann@gmx.de>

I was surprised about this sample too when I have
seen it the first time, this is related to details of
the SMIL timining model.
The basic thing here is about time intervals in SMIL.
This may help:

One always needs an interval to get the animation
started, if any end in the end values list is before
the current begin and no later, the animation cannot start.
And syncbase-values are not added to the end time list
before it really happens, therefore in this case the
animation cannot start, if there are earlier but
no later ends in the list.

Due to the method to get the current interval, such 
a situation is similar to that of an event with a negative
offset. Obviously the viewer cannot start the current
interval before the interval is available, but if it is
available, the animation is the same as if it has started
earlier. For continues animations the effect is better
visible than for this simple animation, if for example
we have values="black;white" (or from="100" to="400") 
for a continuous animation, such a late started animation 
will have a visible start somewhere in the gray, not with 

Why not to add intstance times, when they are known:
There might be a different event that prevent the
syncbase value to exist as an instance time.
And it is simpler for implementors to create the 
instance time lists.
In the section referenced it is therefore noted:
'syncbase-values and media-marker-values are treated similarly. These 
conditions do not yield an instance time unless and until the associated 
syncbase element creates an interval. Each time the syncbase element creates 
a new interval, the condition yields a single instance time. The time plus or 
minus any offset is added to the list. '
Received on Wednesday, 9 July 2008 17:32:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:14 UTC