Re: ISSUE-2083 (Paced-anim-complex): Paced animation and complex types [Last Call: SVG 1.2 Tiny ]

Hi Cameron,


About mathematical correctness - well I learned to
be careful with this ;o)
But your current addition looks ok.

An I cannot see a problem with a values animation with
a single value in SMIL. Because there is only one value,
the animation starts at the begin with this value and
ends with the same value.
I use it often (instead of the simpler set)
and there are no problems for
example with Opera or the adobe plugin.

The problem with the animateMotion path below is,
that somewhere is noted, that M commands do not
consume any time, therefore it is somehow funny, if
the path contains only M commands.
However, the first M is an exception anyway, because
this is indicated to be the start point of the motion,
therefore I think at least this one can be applied.
The question is maybe for a frozen animateMotion, whether
the last M is choosen or not ;o)

Olaf


Cameron McCormack:
> Hi Olaf.
>
> (Again a personal reply, not having been discussed in the WG.)
>
> Dr. Olaf Hoffmann:
> > Indeed, the table was not really necessary anymore. But other
> > more interesting things were removed too while other less interesting
> > things remained.
> >
> > Superfluous things remaining: That 'to', 'from' and 'by' are still
> > mentioned. First, if there is a from-to, from-by or by animation,
> > they are always defined to be equivalent to the related values
> > animation, therefore there is no need to mention them at all,
> > especially because all of them represent values animations with
> > two values, for such paced animations the effect is always the
> > same as for calcMode linear. But because it is only superfluous,
> > it is not problem in general, but if you try to improve clarity, this
> > is maybe a point to think about.
>
> It’s true that SMIL defines from-to, from-by and by animations as being
> equivalent to a corresponding values animation.  But there are many
> things in the animation chapter that simply repeat things from SMIL, and
> since SMIL is normatively referenced these could technically be omitted.
> I think the chapter has a reasonable balance of repeating information
> and leaving the details to SMIL.
>
> > Interesting things removed: The relation between scalars, vectors
> > and a meaningful definiton of a distance somehow related to the
> > definition of calcMode paced.
> > The (wrong) statements in SVG1.1 about paced animateTransform
> > not fitting to the definition of calcMode paced, the wrong, meaningless
> > or not explainable formulas in previous drafts of SVGT1.2 and for
> > example Cyrils comment about paced points indicate already, that
> > it is not trivial to identify, what a meaninful formula for a distance
> > related to calcMode paced is, therefore the relation to scalars and
> > vectors gave at least an idea, that not an arbitrary definition is
> > meaningful, provides some functionality and fits to the definition of
> > calcMode paced.
> > Because this knowledge or finding is lost again in the current
> > wording, there is a high probability to get just other meaningless
> > formulas in one of the next versions, because someone does
> > not understand, what calcMode paced means. Therefore the
> > previous wording was not perfect but still more informative
> > about the real problem of calcMode paced and complex types.
>
> I agree that there have been problems with reasoning for decisions being
> lost over the long time the WG has been operating, but I don’t think in
> general these things need to be included in the spec.  There are various
> other decisions, such as what features were left out for Tiny, whose
> reasons aren’t detailed in the spec.
>
> So yes I thought the previous wording wasn’t perfect, and given that is
> wasn’t required for normative language about how UAs were to behave (and
> that it made the section simpler not to mention it), I removed it.  But
> I don’t feel that strongly about it, so I can restore it (or something
> like it) so that questions about why only these particular distance
> functions are defined can be avoided.
>
> Before, the following paragraph was in that paced animation section
> before the table:
>
>   Distance is defined for types which can be expressed as a list of
>   values, where each value is a vector of scalars in an n-dimensional
>   space. For example, an angle value is a list of one value in a
>   1-dimensional space and a color is a list of 1 value in a
>   3-dimensional space.
>    — http://dev.w3.org/cvsweb/~checkout~/SVG/profiles/1.2T/publish/animate.
>html?rev=1.108&content-type=text/html;%20charset=UTF-8#complexDistances
>
> Perhaps this can be expanded a bit to say:
>
>   Since paced animation is intended to produce an animation with an even
>   pace of change, it does not make sense to define distance functions
>   for all data types.  Distance can be usefully defined for types whose
>   values are n-dimensional vectors (including scalars, which are
>   1-dimensional vectors).  For example, a length value is a scalar
>   value, and a color value is a 3-dimensional vector. Thus these
>   attributes of these types can have paced animation applied to them.
>   On the other hand, a list-of-length (as used by stroke-dasharray) is a
>   list of scalars (1-dimensional vectors), and points-data (as used by
>   the points attribute on a polygon) is a list of 2-dimensional vectors.
>   Therefore, these types do not have a distance function defined and
>   cannot have paced animation applied to them.
>
> (Please check this for mathematical terminology correctness.)
>
> > > There shouldn’t be a problem with segments of an animation having zero
> > > length time.  If it is just a segment of an animation, then that
> > > segment is effectively skipped over, just as if two consecutive
> > > @keyTimes values are equal.
> >
> > No, this was more about some more or less stupid values selections.
> > For any other type it is no problem, because having a similar selection,
> > this results always into having no visible effect at all - and therefore
> > it is not very important, how a user-agent solves the numerical problem.
> >
> > For this simple formula for transform type rotate, there is a visual
> > effect. Assume the following:
> >
> > <animateTransform attributeName="transform" calcMode="paced"
> > type="rotate" values="30,100,0;30,-1000,-100;30,500,-400;30,-600,100"
> > dur="60s" ... />
> >
> > With calcMode linear this results (maybe surprisingly) in some boring
> > translations instead of rotation. With the current formula for calcMode
> > paced the behaviour is critical, plurivalent, because the user-agent
> > cannot calculate the related keyTimes/timing at all.
> > But because there is still a
> > change within the values, the 'error handling' of the user-agents results
> > in some visual effect, which depends on the 'error handling'.
>
> Yes, because of the division-by-zero problem when using the SMIL formula
> (mentioned below), it’s pretty much undefined anyway.
>
> > > If it is the whole animation, on the other hand, then yes the whole
> > > “length” of the animation is zero, which causes problems when using the
> > > formulae in section 3.5.2 of SMIL 2.1.
> > >
> > >   <animateMotion d="M0,0 M100,100 M200,0" dur="2s"/>
> >
> > This problem is specific for animateMotion, nice finding and
> > somehow related to the rotate problem, maybe even worse.
> > What is the timing for calcMode linear here, what for calcMode
> > discrete? ;o)
>
> It seems related to the problem of SMIL 2.1 not defining properly how a
> values animation of a single value is treated.  For linear, going by
> what SMIL says, such an animation would be divided into zero time
> segments (number of values minus one) which doesn’t make much sense.
>
> So I think for now we could leave this undefined, since it’s really a
> corner case with little utility, and since other similar ambiguities
> exist in SMIL.
>
> > > I suppose we could add a small note to say something like:
> > >
> > >   If the total distance of a paced animation (that is, the path length
> > >   in a motion animation, or the sum of the distances between each pair
> > >   of values in other animations) is zero, then the simple animation
> > >   function f(t) is defined to be equal to the final value in the
> > >   animation for all values 0 ≤ t ≤ 1.
> > >
> > > to explicitly define some behavior for this, but I haven’t tested user
> > > agents to see that this is what they in fact do.  It seems to be a
> > > reasonable behaviour to me, though.
> >
> > Yes, something like this would cover such problems. I cannot see
> > some interesting applications for such strange selections of
> > values, therefore my impression is, that it is useful to have a
> > behaviour defined, but not important, which. Typically we will
> > not be able to provide any useful functionality for such things
> > for authors, therefore any simple rule like the above should
> > be ok. If an author uses such values, maybe the only reasons
> > one can image is an accident or to test the existence of such
> > a rule ;o)
>
> Agreed, though as I say above I don’t think it is strictly necessary for
> us to do this right now.
>
> > Concerning the case with rotate above, one could
> > alternatively note, that if the total distance is zero,
> > calcMode paced is skipped and calcMode linear used instead.
> > Then the author still has some continuous effect for the
> > 'stupid' rotate values selection.
>
> That’s also a possibility.  And it would be consistent with other
> zero-distance animations, such as:
>
>   <animate attributeName="x" values="1;1" calcMode="paced" dur="5s"/>
>
> given that truly does have zero distance and only one possible value the
> effect of the animation could have.
>
> > PS:
> > Maybe one thing you have to check, if there is missing a word:
> > "SVG user agents may choose to perform the animation as if
> > calcMode="linear", but this is not required."
> >
> > Is this really complete/correct? Sound a little bit strange to me,
> > but I'm not a native english speaker...
>
> In my mind, I read this as “…perform the animation as if calcMode equals
> linear, …”, so it seems OK to me.  Various other places in the spec use
> similar wording, so I think it’s OK to leave it.
>
>
> So to summarise: my suggestion is to add back in that reworded section
> about pacing and scalars/vectors, and to not add in a note about zero
> distance paced animations.  I’ll ask to discuss this in the WG telcon
> later today, but it would help (due to our time constraints) if you
> could indicate whether my suggested changes would satisfy you before
> then, if possible.
>
> Thanks,
>
> Cameron

Received on Thursday, 30 October 2008 13:55:01 UTC