Re: animate-elem-41-t.svg

Cameron McCormack:
> Cameron McCormack:
> > > I agree, for consistency with the other discrete animations we should
> > > have from="nonzero" to="evenodd" on the fill-rule animations.
>
> Changed now:
> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-elem-41-t.svg

Yes, this avoids the problem ;o)

>
> Dr. Olaf Hoffmann:
> > Do you have in mind, if there is a test/subtest for implicte and
> > explicite discrete to-animations in the W3C-test-suite?
> > Maybe there is no currently - but it would be very useful to
> > test the correct timing.
>
> By my calculations[1], the only one is:
>
> filters-image-02-b.svg: <animate attributeName="xlink:href"
> to="../images/pinksquidj.png" dur="2s" fill="freeze"/>
>

Well, does not look like a test with a focus on this issue ;o)

> so yes it would be good to have some tests for discrete to-animations,
> both implicit and explicit.
>
> > According to my test-suite usual viewers like KSVG1, WebKit,
> > Adobe plugin, Squiggle and Opera have the wrong timing or
> > other problems with discrete to-animations (of course most
> > have problems with to-animations in general, but discrete
> > to-animation is a much simpler issue ;o)
>
> I need to be reminded: is it the case that SMIL Animation (and hence SVG
> 1.1) does not specify the timing of implicit discrete animations (and
> that perhaps SMIL 3 does)?

This was my impression too, before there was a discussion about a
SMIL 3 comment from me ;o) But I got a hint to a place, where I did
not look for this information ;o) Already SMIL animation mentions:
'... a discrete to animation will simply set the "to" value for the simple 
duration.'
It is located at
http://www.w3.org/TR/smil-animation/#AnimFuncCalcMode
below the paragraph about the keySplines syntax.
SMIL2/3 only describe this more formally, SMIL animation uses
more prose, but both are consistent, resulting in the same definition
finally.

Therefore discrete to-animations are almost (?) the same as set animations.
Most SVG viewers use a timing as for values-animations. However, both for
continuous and discrete animation to-animation behaves quite different from
'ordinary' animations - maybe this indicates a requirement to implement it
in a specific way to get the intended behaviour.

Another interesting paragraph about to-animations related to this:
'If to is used without from, (to animation) and if the attribute supports 
addition, the animation is defined to be a kind of mix of additive and 
non-additive. The underlying value is used as a starting point as with 
additive animation, however the ending value specified by the to attribute 
overrides the underlying value as though the animation was non-additive.'
http://www.w3.org/TR/smil-animation/#FromToByAndAdditive

What happens with attributes or properties like fill-rule or XLink:href that
do not 'support addition' or what about lists like viewBox, which are
not additive (what is not necessarily the same, because an can add list
points being only numbers, even if the attribute itself is define to be not
additive - however risky for authors, what is correct behaviour and what
is really implemented. A continuous to-animation is defined to
start additive. This is excluded for list like attributes like viewBox, 
because SVG defines them to be not additive, therefore viewBox shares
the behaviour with fill-rule etc). 
Is the to-animation in general only defined for attributes and 
properties, that 'support addition'? If yes, then to-animations should
only be used for those, which 'support addition' and never for others, 
what could apply as well for discrete to-animations, following this
interpretation.
The other interpretation could be of course, that if the attribute or
property or its values are not additive (for example the overloaded 
fill and stroke properties can have 'none' or a paint server as 
underlying or to value with the result, that they do not 'support addition' 
in this case), this results automatically in a (defined) discrete
to-animation, because this does not require an additive start - implicit 
discrete animation, my preferred interpretation and something that is 
better implementable than an undefined animation ;o)
However especially with interactivity one can create examples
with such problematic properties like fill, where it is not predictable
at the begin of an active duration, whether the animation should be 
discrete or can be continuous (what applies of course for other additive
animation types as well) - what is more a problem of SVG than of
SMIL, that could have been avoided with attributes strictly
having either additive values or not additive values and not such
a wild mix like fill or stroke.

Olaf

Received on Tuesday, 23 November 2010 10:46:21 UTC