Advanced SVG Animation Techniques

OK, so you have animated SVG, but how to control it? Scripting SVG via the DOM provides the answer.

( Read the article )

I'm tracking this thread if anyone has questions about the article or topics they'd like me to approach for upcoming articles.

Great and useful paper, Antoine, but can you tell us more about the compatibility with SVG implementations made by Mozilla and Adobe ? IMHO, the main actual problem with SVG is that it is always difficult to get animated SVG working on all three platforms.

thanks,

Originally posted by gerardlambert:

can you tell us more about the compatibility with SVG implementations made by Mozilla and Adobe ?

This code will not work in Firefox, or any other application using the Gecko rendering engine, as that codebase does not support in any capacity the SVG animation primitives. This is a known issue, and there has been work done on the topic, but this code has not been truly tested or integrated in Mozilla's codebase. There have been talks of supporting SVG animation for Firefox 3.0, but I think that nothing is cast in stone here.

As for the Adobe SVG Viewer, the code should normally work, but I've noticed there are issues with both samples, so I will check this in more depth when I have some time.

IMHO, the main actual problem with SVG is that it is always difficult to get animated SVG working on all three platforms.

I agree, and this is an issue that needs to be taken head-on with the various other browser makers, who need to get clear feedback from their user community that this is a feature that they care about.

Originally posted by graouts:

this is an issue that needs to be taken head-on with the various other browser makers, who need to get clear feedback from their user community that this is a feature that they care about.

Sure, blame us... But yes, this is going to stay a problem. As I see it, it is similar to the situation we've had with CSS, only worse. Even given the browser wars and all that, at least the browsers come from the same world (well, things like Prince have expanded that world a little). With SVG you have the phone world, the standalone SVG viewer world, recently the browser world, and probably others. With CSS we realised that interoperability is the key, starting the CSS 2.1 process. But it is telling that from the very first CSS proposal (1994) through CSS1 (1996) to CSS2 (1998) took three and a half years, we've spent five years on the compatible version, and it's still only formally halfway on the standards track. Not only CSS, SVG 1.2 is about as old and with considerable effort and strife behind it, and most likely ahead of it too. With that in mind it is almost rude to say that SVG can't stop there, that it needs its own 2.1, as does the rest of the W3C in my opinion.

But at least SVG is not in a situation where it would be in anyone's interest not to be interoperable. To some extent that happened with the Adobe SVG Viewer, with an absolute dominance on the desktop market, the most complete support of SVG, and quite a few quirks on its own. In time our dilemma might have been whether we should align ourselves with the standard or with ASV. While Adobe's withdrawal from SVG is bad for the business at least that particular problem didn't arise.

There is no quick fix, for SVG, CSS, or anything else. As SVG is a big spec, complete and error-free implementations are not going to happen any day soon by anyone. ASV has been closest to being complete, but it isn't error-free. Some parts like animation and scripting are optional, Firefox has opted out of animation, others have opted out of scripting, so techniques using both is not going to reach everyone. What can be done is to make SVG versions of acid tests or similar for the features that are crucial to get right, and sensible fallbacks for when a feature is unsupported.

For many of our articles we have an Implementation notes section at the end, for practical issues like browser support or editor support. It can be an idea to add one to this article too.

Originally posted by jax:

Some parts like animation and scripting are optional, Firefox has opted out of animation, others have opted out of scripting

Animation is not optional. It is a required part of every formal SVG version. Scripting is not required in them all. Firefox just hasn't done the implementation work yet, although because scripting in SVG is based on DOM they were able to do that relatively easily.

Unfortunately, if they become an important player in SVG (as they show every sign of doing) this means that they will efectively hold back SVG developers in much the same way that IE and Netscape held back HTML at various times in the past.

Doug Schepers has done some work to make at least a passable extension that implements animation in javascript, but it's not really a nice way around the problem as he himself admits. Still, better than not being able to use animation at all...

I noticed this statement in the article,

Originally posted by graouts:

Today's web applications, thanks to the advent of AJAX clearing JavaScript's bad name, are very interactive and heavy on script-based logic.

So I am curious, what bad name did JavaScript have before, and how did AJAX clean it?

My post is bit of side tracking but ... since this place is for developers using Opera, i was wondering if a tool could be created in opera that could use Opera's page thumbnailer to create screenshots of svg.
'Why?' you might ask, well.. since IE en FF don't support (animated) svg, we could serve them bitmap slides instead.
If the svg animation is a 'movie', then provide an animated gif or, frames controlled by some javascript.
If the animation is about interacting: maybe add support for clickable bitmaps that trigger javascript events to replace the current bitmap with another?

Personally, i'm amazed that svg adoption is so slow. Designing web pages is much easier with svg then with html/css, the latter still having an internal logic based on the old paper book format (title, paragraphs, table of contents, etc.)

FireFox 2 render it, but strange as it may seem not process onclick and FireBug report:

animations.beginElement is not a function


So article is very good. Thanks!

ps - IMHO JavaScript just rebirth within AJAX

Post edited Tuesday, 21. November 2006, 18:05:53

Originally posted by foxweb:

FireFox 2 render it, but strange as it may seem not process onclick and FireBug report: animations.beginElement is not a function

Hi. This is to be expected as Firefox does not support native SVG animation constructs derived from SMIL, and thus not the beginElement() method. This is something to look forward to in future versions.

Antoine

I know this is probably a bit of a rabbit trail, but I'm curious to know if anyone can recommend a good approach for simultaneously animating rotation of a relatively large number (say, 200+) of path elements in a single SVG document. We've tried the declarative approach as well as JavaScript, and neither seems to scale very well for our SVG markup. We're declaring <path> elements in the <defs> section and adding <use><animateTransform/></use> syntax in the document.

SMIL animation with ASV/IE breaks down and starts crashing the browser at around 80 elements, and seems a bit choppy in Opera. Also, the host CPU utilization spikes up to 100% in both browsers.

Animating rotation using plain vanilla JavaScript is just plain choppy, and slows considerably as you increase the number of elements being animated.

We're going to give the technique described in this article a try next.

Perhaps there is a problem with our SVG markup? Or perhaps SVG animation isn't meant to be applied to hundreds of elements simultaneously?

If anyone is interested in seeing a sample svg file that illustrates the problem, please reply and I'll post one for you.

Originally posted by integragreg:

I know this is probably a bit of a rabbit trail, but I'm curious to know if anyone can recommend a good approach for simultaneously animating rotation of a relatively large number (say, 200+) of path elements in a single SVG document. We've tried the declarative approach as well as JavaScript, and neither seems to scale very well for our SVG markup. We're declaring <path> elements in the <defs> section and adding <use><animateTransform/></use> syntax in the document.SMIL animation with ASV/IE breaks down and starts crashing the browser at around 80 elements, and seems a bit choppy in Opera. Also, the host CPU utilization spikes up to 100% in both browsers.

It's difficult to say without seeing the svg source, but if you can combine the paths into fewer elements that is likely to help performance. Other things like opacity and filters are expensive. If you can avoid having strokes on your paths that'll help a little. Stroke- and fill-opacity gives a minor performance penalty, but not as much as opacity. Grouping things so that they may share animation elements might be a good idea if there are alot of animation elements in the tree.

If you could post the svg it might be easier to say what exactly is slowing it down.

Antoine this article helped me out of a hole, thanks ~:"

However I raised bug-275925 as when begin is not indefinite, similar code runs once onEvent, but not again.

What's your take on that?
should animation start when the script runs the first time?
if so should it run each time the script appendsChild?

Peepo,

I'm not sure what you're refering to as "onEvent", can you clarify?

Antoine

Found this very interesting but I still have one problem.
It all works fine for me as it should but I want to do the same for animateMotion.

I really like to do it all in script and usually have.
I just cant seem to figure what I'm missing.
Logically the same procedure should work for animateMotion but does it have any special needs?

I am afraid I don't understand exactly what you want to achieve, but is this article of any help?

Thanks for the quick reply.
I've seen that one already.
I guess its easy to forget that other people cant see whats on your mind, lol.

I'm just fascinated by scripting, by svg and especially making them work together, so this is just out of interest for me. Early stages of a little fun project.

Basically I can get the animations done using the literal approach.
ie - something in the svg space like
<g>
<use id="loco1" xlink:href="#dslsw">
<animateMotion id="T1anim" dur="10s" begin="0s" rotate="auto-reverse" fill="freeze" >
<mpath id="T1path" xlink:href="#T1mid"/>
</animateMotion>
<animateMotion id="S1anim0" path='' dur="3s" rotate="auto-reverse" fill="freeze" begin="T1anim.end" >
</animateMotion>
..... etc

and it all works fine but I always feel I should be able to do it in the script/dom way.
This gives more flexibility, more power and more reusability.
I like things to be so that I can easily add parts later [build for the future].

I can put most all of it in scripts similar to whats been done in this article.
But everything I find anywhere always talks about only animateTransform.
No-one seems to have done the same for animateMotion.

Logically it should be straightforward if you can the former.

Looking at the structure you should be able to attach an animateMotion to the thing you want to move in the same way as you can an animateTransform [such as in this article] but I cant seem to get it to work.

Obviously its just some small detail, some extra setting I am missing, but what?
Since no-one seems to have done it I cant find an answer.

If it works within the svg structure, and it positively does, it should be addressable as part of the dom and hence scriptable.

Any suggestions?

Usually I just extensively experiment and test but so far no luck!

I've developed all kinds of weird techniques for testing in the past but nada!

Still, I'm having some good fun, lol!

I can do this the wrong way but its seems clunky.
Since the earlier post I've figured a sort of work around to at least let me access things but I always feel there must be a way to do it right!

Just to let anyone reading this know I've solved the problem.
Not even sure why it didn't work before.

Frankly though the irony is I dont think the method will work for what I want to do.
Not a waste though since Ive learned more about it for future use and besides its still good to use for the automated parts.

with an animateMotion I appreciate you can use begin='' and end='' to set WHEN it begins or ends, but can you set something to happen WHEN it ends, for eg, call a function?