W3C home > Mailing lists > Public > www-svg@w3.org > November 2002

Re: Declarative animation limitations

From: Chris Lilley <chris@w3.org>
Date: Wed, 27 Nov 2002 14:06:31 +0100
Message-ID: <42285504031.20021127140631@w3.org>
To: www-svg@w3.org, ksmrq@netscape.net

On Sunday, November 17, 2002, 3:14:30 PM, ksmrq wrote:

knn> ********************
knn> Without my elaborate workaround I cannot smoothly animate any
knn> quantity. Not rotation angle, not scale value(s), not
knn> feGaussianBlur's stdDeviation, not an feOffset, not a circle
knn> radius, not anything. I can piecewise linearly interpolate.
knn> Period. Unless, just by luck, I happen to want to animate the
knn> translation of an entire graphic object. How dumb is that?!
knn> ********************

It would be very dumb. But I am puzzled by your assertion that only
linear interpolation is possible.

knn> Suppose I want to animate a scalar quantity, such as opacity, but
knn> that I am not satisfied with piecewise linear interpolation.
knn> Sorry, not possible.


calcMode = "discrete | linear | paced | spline"

keySplines = "<list>"

A set of Bézier control points associated with the keyTimes list,
defining a cubic Bézier function that controls interval pacing. The
attribute value is a semicolon separated list of control point
descriptions. Each control point description is a set of four values:
x1 y1 x2 y2, describing the Bézier control points for one time

OK so you don't want linear, paced does not help this case too much
either, discrete makes it worse but spline seems like a good fit, no?

knn> Yet if I want to speed it up or slow it down
knn> *on that linear path*, I can. Or if I want to *translate* an
knn> object along a curved path, I can. Clearly an implementation must
knn> already have a sophisticated facility for animateMotion, yet I
knn> have no access to it for anything else.

You are right that there is big potential for code reuse here in the
implementation, but seemingly incorrect that this code can't be used
to smoothly interpolate a value using a set of peicewise bezier
curves, unless I have misunderstood what you are asking for.

knn> If declarative animation is meant to be taken seriously, for
knn> environments without scripting, this serious design flaw should
knn> be fixed ASAP. I know my way around computer animation and the
knn> mathematics of curves far better than most users, yet I found the
knn> construction of a workaround challenging. To me it seems obvious
knn> the need for a simple smooth interpolation facility exists. I
knn> cannot imagine the typical graphic artist finding my method. In
knn> fact, I rather doubt many graphics programmers would.

knn> Is my general description of uses clear enough? If not, I'm sure
knn> I could devise an endless stream of specific uses. I had hoped
knn> that would be clear to the folks I expected to look at my post,
knn> but perhaps I was optimistic.

No, it was not optimistic, but it also seems clear that SVG has
methods beyond simple linear interpolation so, I am not sure what the
misine piece is here.

knn> I have posted the issue for four reasons: 1) self defence, to
knn> avoid being encumbered by a bad design myself; 2) community
knn> service, to improve the design for everyone; 3) education, to
knn> show those who seek a workaround how it may be done; and 4) self
knn> expression, because I was so disturbed by this.

It was a good and motivating example. I agree that an interpolant such
as you used in your example is not currently possible, but disagree
with your assertion that an opacity or radius can only be interpolated
in piecewise linear fashion.

knn> I'll be happy to answer further questions. Or just tell me
knn> declarative animation is not meant to be taken seriously and I'll
knn> go away quietly.

Don't go away, but please help explain what the missing piece is for
the animation of, say, the radius of a circle. It seems like a bunch
of piecewise beziers give quite a lot of control there?

 Chris                            mailto:chris@w3.org
Received on Wednesday, 27 November 2002 08:06:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:54 UTC