Re: Declarative animation limitations

>>>>> "ksmrq" == ksmrq  <ksmrq@netscape.net> writes:

ksmrq> AndrewWatt2001@aol.com wrote:

>> You're welcome Ken. I took time to look at it primarily because I
>> found your comments genuinely interesting. Although I wasn't
>> immediately sure why you seemed so frustrated. :)

ksmrq> Thanks. As for the frustration, imagine you wanted to start a
ksmrq> new car and discovered the ignition switch was in the back
ksmrq> seat.

       For us backseat drivers that is quite convenient :)

>> I haven't had time yet to read through the SVG 1.2 Working Draft
>> but, as I recall, the SVG 1.1/1.2/2.0 Requirements document
>> indicated that additional declarative animation would, at a
>> minimum, be explored. So if you want to see more features added
>> then pitch in with specific positive ideas.

ksmrq> The documents on the web, via <http://www.w3.org/TR/SVG2Reqs/>
ksmrq> and so on, are brief and sketchy. Nothing I see there indicates
ksmrq> an awareness of, or attention to, the issue I am raising.

       I think this may have been mentioned when SVG 1.0 was wrapping
up but was probably just too large a change for serious consideration
at the time, however now is probably an excellent time to discuss this
sort of issue.

ksmrq> First, may I take it as implicit in the discussion so far that
ksmrq> I *have not* overlooked something in the current REC? That to
ksmrq> do non-linear interpolation of arbitrary values I must use my
ksmrq> workaround? Because documents of that sort are notorious for
ksmrq> obscuring possibilities.

       To be quite honest I'm not to most knowledgeable person on the
details of the declarative animation parts of SVG so it may be that
there is another way, but I don't believe so.

ksmrq> Second, if indeed the facility does not exist, I believe SVG
ksmrq> (perhaps 2.0) and SMIL should incorporate it. Specifically, the
ksmrq> (poorly named) spline timing facility needs to have a twin that
ksmrq> applies to values as well. 

       I think the issue here is the design of the path element.  The
current methodology basically relies on saying there are two versions
of the 'd' attribute for the path and you just linearly interpolate
between them.  This is really convenient because it means no new
syntax or parsing is required to support this feature, also no new
objects/interfaces need to introduced for DOM.

       For your proposal things get a _lot_ more complex, in the
simplest syntax I can imagine for bezier interpolation of values you
provide four 'd' attributes, initial, cp 1, cp2, final.  The awkward
part is that for the control point 'd' attributes you end up still
having things like 'M' 'l' etc it's just that the values no longer
really represent a move they represent a control point on the move
spline - this is also clumsy as it requires the same types of
animation for all elements in a path.

       I suppose I could also see a version where the d-spline
attribute would have three values for each value in the existing path
or a paired syntax "mc 1,2,3 4,5,6 ll 3,4" So the first would be a
move with cubic interpolation and the second would be a line with
linear interpolation.  This is getting a bit better, but makes the
syntax for this 'd-spline' attribute exorbitantly complex for XML.

       Does this get close to the types of things you are looking for?

       Additional suggestions?

ksmrq> Even better would be real splines for both, with control points
ksmrq> and knots giving automatic continuity. It is absolutely
ksmrq> essential for animation splines to use non-uniform knot vectors
ksmrq> so that control values can be inserted and deleted with only
ksmrq> local effects. An example of what is possible can be found in
ksmrq> my DialASpline routine in Graphics Gems V.  "Linear Form
ksmrq> Curves", Graphics Gems V, Academic Press 1995, Paeth, 210-223
ksmrq> <http://www1.acm.org/pubs/tog/GraphicsGems/gemsv/ch4-9/>

       Well, I'm hoping that the authoring tools can meet up 1/2 way
here.  SVG is largely intended to be rendered 'in real time', from
what I know non-uniform splines are significantly more expensive to
evaluate than simple beziers (of course they are much nicer
mathematically speaking).

ksmrq> Third, arc/elliptical animation should be added. As a general
ksmrq> principle, if you can draw a path you should be able to use it
ksmrq> for animation as well. SVG should not be encumbered with SMIL
ksmrq> limitations, nor need SMIL adopt all the paths appropriate for
ksmrq> SVG.

       Yah, not sure where this falls on the scales, I know that most
implementations turn elliptical arcs in paths into beziers as soon as
they can, so I'm not sure how much you would gain in doing this,
probably this would depend greatly on the approach taken above for
describing interpolation of path elements.

ksmrq> Fourth, SVG should provide a uniform mechanism for accessing
ksmrq> vectors, both as a pair and as components. For example, the
ksmrq> center of a circle should have a center="x y" form as well as
ksmrq> the current cx="x" cy="y" form. Conversely, paths should allow
ksmrq> x and y to be separated. (That would fit in nicely with the
ksmrq> animation needs, but greatly amends paths.)

       This is starting to really muck with the language, what do you
do if both are provided in content?  via DOM? etc.  Remember this
isn't like C++ where you can trivially have 'double getX()', 'double
getY()', 'Point<double> getXY()' - every time you add a attribute to
an element you add to the infoset ('data members') of that element.

ksmrq> Fifth, the timing along paths in players needs to be more
ksmrq> carefully stated. (Either that or Adobe's implementation is
ksmrq> buggy. When I used animateMotion to move a circle along a curve
ksmrq> the timing did not match that of my kludge, even though the
ksmrq> geometric paths matched, for neither "linear" nor "paced".)

       Can't comment.

ksmrq> Sixth, help the Mozilla guys get a fully working SVG. Well, OK;
ksmrq> that one's a little selfish. :)

       Have you taken a look at Batik?  Another open-source
implementation of SVG, in Java.  The one big thing it's missing is
SMIL animation.  Otherwise, it does very good on the SVG test suite.
It might make a good demonstration platform (ok so this is a little
selfish as well).

ksmrq> Finally, when I view an SVG file I don't know if I'm going to
ksmrq> see a movie or a still, but I believe (with the developers of
ksmrq> PNG/MNG) that I should be told in advance.

       Good point.

Received on Monday, 18 November 2002 09:07:37 UTC