Re: Declarative animation limitations

AndrewWatt2001@aol.com wrote:
>I am not trying to provoke you with the following question but I am 
>genuinely wondering why you think the effect you created should be 
>particularly easy/succinct to do.
>There are lots of effects which are in the "nice to have" category. But you 
>seem to be assuming that the effect you illustrated is not only in the 
>"nice to have" category but is also important.
>What would the use case be?

Thanks for taking the time to examine the issue.

What I have managed to do, painfully, is declaratively animate *any* quantity I choose through a continuous sequence of values controlled by Bezier (up to cubic) control points. (I do not show it, but I can also work in a power basis.) My example gives all the details needed for others to copy my method. For example, to animate the radius of a circle using quadratic Bezier control values 3.14, 1.414, 2.718, the SVG would read thus:

  <circle x="0" y="0" r="0">
    <animate attributeName="r" ... values="3.14;0" ... />
    <animate attributeName="r" ... values="0;0.707;0" ... />
    <animate attributeName="r" ... values="0;2.718" ... />
  </circle>

Of course the bits I have elided are the critical details of *how* I do it; but you had asked about *what* I might do.

If all I was illustrating was the difficulty of moving one end of a curve along a Bezier path, I might not have bothered. However when I look closely at what SVG provides for animation, I am troubled by the elaborate controls for timing but complete lack of control of the nature of the interpolant.

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

Suppose I want to animate a scalar quantity, such as opacity, but that I am not satisfied with piecewise linear interpolation. Sorry, not possible. Yet if I want to speed it up or slow it down *on that linear path*, I can. Or if I want to *translate* an object along a curved path, I can. Clearly an implementation must already have a sophisticated facility for animateMotion, yet I have no access to it for anything else. My example illustrates how ridiculous it is to be able to easily draw a curve or to animateMotion the whole thing, yet have no way to smoothly move a quantity like one end. Since the tangent of a cubic Bezier curve is a quadratic Bezier curve, I used that as a way to give the necessary workaround for both. (Linear does not require a workaround, of course.)

The fact that the time controls are so elaborate that I was able to create such a kludge, yet the value controls are so primitive I had to, is bad design. I would never design and have never used an animation system that denied me the ability to control the smoothness of my interpolants. To me that's Animation 101.

It embarrasses me to raise the issue, because I find it hard to believe that a committee knowledgeable enough to design SVG wouldn't feel the same. As I fought to find a way around the problem, I constantly returned to the REC to convince myself I hadn't overlooked such a basic facility. I still half expect someone to correct me.

The only conclusion I could draw was that declarative animation is not meant to be taken seriously. Scripts and the DOM are the intended method.

Examples that support this supposition include the otherwise bizarre use of coordinate pairs for some uses but separately named x and y attributes for others. (Yet even in a DOM this is awkward.) This effectively precludes uniform access and animation. Thus if I had used a "line" instead of a "path", my example would have been even more painful, because I'd need separate animation for x2 and y2.

At least that's how I read the REC.

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

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

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

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


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Received on Sunday, 17 November 2002 09:15:18 UTC