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

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

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 30 October 2008 01:11:10 UTC