W3C home > Mailing lists > Public > www-svg@w3.org > March 2009

Re: [SVG Transforms 1.0, Part 2: Language (2009-03-20)] - Feedback for "4. 'animateTransform' Extensions"

From: Rick <graham.rick@gmail.com>
Date: Mon, 23 Mar 2009 22:50:11 -0400
Message-ID: <18569e000903231950p48e56eb8o37b69ee00e8bc85b@mail.gmail.com>
To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
Cc: www-svg@w3.org
2009/3/22 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
> Hello SVG WG,
> mainly a suggestion for this section:
> Consider the type matrix to be animatable too, this can

My $0.02, I've noticed that doing transformations with matrices is
noticeably more efficient than with lower level transforms, presumably
because they are multiplied out to matrices anyway and that step is
skipped.  I can't say that I've tested this everywhere, but this is
the case in Firefox at least.

Matrix animations would be nifty.

> be pretty useful for some types of computed structures,
> for example animated IFS (iterated function systems).
> Authors today have to construct huge workarounds to
> get a similar effect, because currently matrix is not
> animatable.
> For example one can workaround it with a huge values
> animation of xlink:href of use referencing different
> static transformed pattern in the defs elements,
> about 20 pattern per second animation. This can be
> simply avoided, if matrix would be animatable.
> In some versions of Opera this is available and
> can be tested.
> If matrix animation is implemented, this could (almost)
> solve the current problem with a to animation
> for animateTransform to meet the SMIL requirement
> to have a smooth and continuous animation from
> the underlying value to the to-value.
> One simply can calculate the underlying value
> and the to-value as matrices and to interpolate
> between.
> For some specific simple cases authors may expect
> another behaviour (for example if the underlying
> value is rotate(360) and the to value is rotate(0)),
> but these simple cases can be typically covered
> easily with from-to or values animations,
> the typical SMIL effect, the basic functionality
> for to-animations not.
> Note, that skewX and skewY are mentioned here, but
> not in section 3. Because there is no skewZ, this is
> ok for section 3, for 4. however they can be skipped,
> because the section title indicates, that it is
> only an extension. Whatever is done, I think, at
> least 3. and 4, should be consistent and the titles
> of the sections should fit to the content ;o)
> Best wishes
> Olaf

Received on Tuesday, 24 March 2009 02:50:45 UTC

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