XML.com: Digging Animation

Digging Animation
by Antoine Quint | Pages: 1, 2

Getting Our Mouse To Work

So far the work we've done, while valuable, is still a little lame. Niklas had his cubes reacting to mouse events generated when the user rolled over them. Let's get that to work, too. SVG animation provides a mechanism for reacting to mouse events. You might have noticed that in our previous animation we did not specify when our animation started. There is an attribute "begin" that would do exactly that, but it has a default value of "0s", which means our animation starts when the document is loaded. Here we want our animation to start when we mouse over the cube. Let's try introducing the "begin" attribute to our animation and set it to "mouseover", and see what it does:

<use xlink:href="#cube" transform="translate(307.5, 105.75)">
  <animate attributeName="y" begin="mouseover" dur="2s" 
           values="0; -45; 0; 16; 0; -7; 0; 3; 0; -2; 0; 1; 0" />
</use>

[View this code as SVG]

If you tried rolling your mouse over the cube you will have noticed it did start the animation. You might also have noticed that there is a bit of a strange behavior going on. If you don't move your pointer away from where you entered the cube and started the animation, then the animation will restart from the beginning when the cube falls down and goes under your pointer again. This is not what we want; we would rather have the cube not take any mouse event until the animation is finished. Once again, SVG animation provides the exact mechanism we are looking for: the "restart" attribute. By default its value is set to "always", which means that the animation is restarted at every time the situation indicated by the animation "begin" attribute is true. Another possible value is "whenNotActive", which according to the spec means that "the animation can only be restarted when it is not active [and that any] attempts to restart the animation during its active duration are ignored". This sounds like what we have been looking for, let's see how it goes:

<use xlink:href="#cube" transform="translate(307.5, 105.75)">
  <animate attributeName="y" begin="mouseover" restart="whenNotActive"
           dur="2s"
           values="0; -45; 0; 16; 0; -7; 0; 3; 0; -2; 0; 1; 0" />
</use>

[View this code as SVG]

This is exactly the behavior we wanted. Excellent. However, we still have some way to go to a refined animation like the original. Let's move on to better things.

Upping the Pace

The key ingredient to make our animation as spiffy as Niklas's is to give the animation a acceleration/deceleration, gravity-like feel. When I opened the original source file in Flash, I noticed Niklas did two things. The first thing was adjusting the keyframes so that the animation would have different intervals between two sets of values. The other was to have easing-in and easing-out on certain intervals of the animation. Let's see how to implement that in SVG: keep your eyes peeled as this is really is the hottest part of what SVG animation offers.

Our first task is to get the values to be taken into account at non-identical intervals in time. It is time to introduce a new attribute to our growing set of friends: the "keyTimes" attribute. This attribute will help us recreate the timing that was going on in the original SWF animation; it will help us create a mapping between the "values" attribute and the time at which each value will be reached in our animation. The SVG specification says that "each time value in the keyTimes list is specified as a floating point value between 0 and 1 (inclusive), representing a proportional offset into the simple duration of the animation element". Albeit in formal terms, this is what we are after. Let's give it a shot:

  <use xlink:href="#cube" transform="translate(307.5, 105.75)">
    <animate attributeName="y" begin="mouseover" 
             restart="whenNotActive" dur="2s" 
             values="0; -45; 0; 16; 0; -7; 0; 3; 0; -2; 0; 1; 0"
             keyTimes="0; 0.2564; 0.5128; 0.6154; 0.6923; 0.7436;
                       0.7949; 0.8462; 0.8974; 0.9231; 0.9487;
                       0.9744; 1" />
  </use>

[View this code as SVG]

Pay no attention to the weird values we set in the "keyTimes" attribute. These were computed by hand from the original Flash animation. It looks kind of odd because Niklas's keyframes were placed themselves at odd times. This is of course a job best suited for an SVG-enabled animation authoring tool, but here we're trying to figure out how SVG animation works exactly so it is worth doing by hand. The result we have now is somewhat paced animation. It is not as refined as Niklas's yet, but the end bit looks exactly like it ought to. As for the start of the animation, this is where Niklas had the easing-in and easing-out take place. Now watch out, because this is getting really smooth.

In Macromedia Flash 5, one can specify easing-in and easing-out between two keyframes with a percentage ranging from "-100%" to "100%". Although this is quite a jolly nice control over acceleration, SVG provides a much sweeter mechanism. Instead of having a simple percentage, SVG allows us to describe the speed behavior of an animation interval with a two-point Bezier curve (you've probably heard a lot about those if you've got any experience with SVG). What does this mean?

Draw a Bezier spline that fits in a square, starting bottom-left going top-right. The rule to draw that kind of curve is that it has to be bijective (a unique mapping of x and y). You can find quite a few of these curves just above section 19.2.8 of the spec, which are really helpful in visualizing how keySplines work. Now the x-axis represents time and the y-axis represents the percentage of the variation between the two values. That allows us to have very fine control of animation speed. While Flash only allowed us to specify constant speed variations, SVG enables multiple speed variations in one given interval. Now that we have a better idea of how keySplines work, let's put our knowledge to work:

  <use xlink:href="#cube" transform="translate(307.5, 105.75)">
    <animate attributeName="y" begin="mouseover"
             restart="whenNotActive" dur="2s" calcMode="spline"
             keySplines="0 .75 .5 1; .5 0 1 .25; 0 .25 .25 1;
                         .5 0 1 .5; 0 0 1 1; 0 0 1 1; 0 0 1 1;
                         0 0 1 1; 0 0 1 1; 0 0 1 1; 0 0 1 1; 0 0 1 1"
             values="0; -45; 0; 16; 0; -7; 0; 3; 0; -2; 0; 1; 0"
             keyTimes="0; 0.2564; 0.5128; 0.6154; 0.6923; 0.7436;
                       0.7949; 0.8462; 0.8974; 0.9231; 0.9487;
                       0.9744; 1" />
  </use>

[View this code as SVG]

Now this looks nice, much like the real thing, in fact a lot smoother since we did not have to worry about the cumbersome frame-rate. Besides the "keySplines" attribute we just introduced, you will have noticed a new friend: "calcMode". This attribute enables tweaking of the way the interpolation between the animation values we set is done. So far, we have use its default value ("linear") and now we needed to set it to "spline" so that it would take into account our "keySplines" attribute.

Go Forth And Multiply!

One of the last things missing is actually having the sixteen instances of our cube. Since we defined our cube as an SVG "symbol", we only have to place sixteen "use" elements, much like we have used so far with our single cube. I'm not going to teach you how to line cubes up, I actually got Illustrator to give me the bounding box of the cube and did a rough alignment by hand (you can see it's not perfectly aligned when you zoom in).

In much the same way as we created a symbol for the graphics in order to create a single definition for multiple re-use, we may well want to have references to our animation since all the cubes are animated in the same way. We could have had our "animation" element as part of the symbol, but the SVG 1.0 specification states that this would result in all instances of the symbol being animated at the same time. However, animation referencing is an issue being addressed by the W3C SVG Working Group for future enhancements, and SVG 1.1 (currently in Working Draft status) introduces a mechanism allowing for animation of animated symbol instances only. Still, there is a way to actually re-create this kind of behavior, using entities. The idea is to have all the sensible values of our animation, which may be changed in our authoring, be centralized so that a single change would be applied to all the animations. Here goes:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
          "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [
  <!ENTITY dur "2s">
  <!ENTITY values     "0;    -45;      0;     16;      0;     -7;
                       0;      3;      0;     -2;      0;      1; 0">
  <!ENTITY keyTimes   "0; 0.2564; 0.5128; 0.6154; 0.6923; 0.7436;
                  0.7949; 0.8462; 0.8974; 0.9231; 0.9487; 0.9744; 1">
  <!ENTITY keySplines "0 .75 .5 1; .5 0 1 .25; 0 .25 .25 1; .5 0 1 .5;
                       0 0 1 1; 0 0 1 1; 0 0 1 1; 0 0 1 1; 0 0 1 1;
                       0 0 1 1; 0 0 1 1; 0 0 1 1">
  <!ENTITY calcMode "spline">
  <!ENTITY begin "mouseover">
]>

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="0 0 665 250" xml:space="preserve">

  <!-- <title>, <defs> and background <rect> as we have seen -->

  <g id="cubes" transform="translate(300.25, 143.45)" >
    <use xlink:href="#cube" transform="translate(0,-72)">
      <animate dur="&dur;" values="&values;" keyTimes="&keyTimes;"
               keySplines="&keySplines;"
               attributeName="y" begin="&begin;" 
               restart="whenNotActive" calcMode="&calcMode;" />
    </use>
    <!-- fifteen other <use> -->
  </g>

</svg>

[View this code as SVG]

Et voil�!. This might well look like a dirty trick, but it does the job quite nicely. Now if we decide to change the keySpline for the third interval of our animation, we only have to edit it once. As for the animation itself, it looks like we're done. It should look very much like the original SWF version. In fact, Adobe's SVG Viewer on my laptop gives me a much smoother animation than the SWF played in the Flash player. By the way, the gzipped version (commonly known as SVGZ) of the final animation is only 891 bytes, while the SWF version is 1.29 KB. Prettier and smaller!

Wrapping It All Up

I hope you enjoyed this ride through some of the nicest features of SVG animation. There is a lot more to SVG animation, especially the idea of synchronization, which we'll consider in future articles. I think this simple animation highlights some of the key concepts of SVG animation, primarily that it is time-based and property-based, as well as some of its differences from the SWF animation capabilities.

It's probably now time for you to read the whole animation chapter of the SVG 1.0 specification and start digging into it yourself. One thing you'll find missing at the moment is an authoring tool for SVG animations. Jasc's WebDraw 1.0 has just been announced and includes support for some of SVG's animation features. And Adobe just recently asked on the SVG-Developers list for feedback on the need for SVG support in their animation tool, LiveMotion. Adobe is soliciting your input on its email wish list. If you want to see SVG grow in terms of user penetration and ease-of-use, make sure Adobe and other vendors hear from you.

Comments or questions about this article? Let us know by using the forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only

Newest First

Locksmith Los Angeles 1-818-386-1022 Locked Out Install Repair Open Locks Los Angeles Locksmith
2008-10-24 23:11:17 orellytos [Reply]

AA Locksmith Los Angeles 1-818-386-1022 all locks install rekeying locks and locked out services 24 hour.

Great article!
2002-07-15 18:13:23 Tom Hart [Reply]

This is a good example of where SVG is now at only version 1.0 in relation to Flash at version 5 or 6 (whatever MX is).

Thanks Antoine!

Input Text
2002-05-08 11:33:17 Mark Zartler [Reply]

SVG is nice, but it's not interactive enough to use as a drop in replacement for flash. Specifically, there are no provisions for input text- a feature I use all the time in flash.

Show me the way to join SVG and ASP.
2002-05-06 22:19:07 BYOUNG HEE HA [Reply]

It's very good your articles about SVG Animation in "http://www.xml.com". (I'm sorry that I don't know English well. and then...I hope that you will read this content with a full understanding)
I am from KOREA.(KOREA is the host nation of "THE 2002 FIFA WORLD CUP")
Now I'm studying XML,XSL,ASP,MS-SQL and SVG.
I don't have much experience in SVG programming yet.
I have a question about SVG animation
This question has connection with ASP and SQL.
I'm planning Project using XML,SVG,WML,ASP and MS-SQL.
It is management system for construction materials
(Because of MY major is architecture engineering.)
My plan is showing living statistical data by chart,graph so on....
So I need SVG CODE.
Please..Show me the way.
How do I mapping SVG and ASP?
Or...other way is good to me.

Prettier and smaller!????????
2002-04-19 00:39:19 Muzak Deezign [Reply]

Just did something similar using actionscript in flash MX - so no tweening animations.
The size (width and height) of the movie and the cubes is about twice as big as the svg thingy, the filesize: 840 bytes

Furthermore, I turned this movie into a Component, which means ANYONE can easily adjust the animation (speed, bounce, etc...).
Also, turning this into a component made the filesize larger, so if I wouldn't have done so, I'd probably have a 500 bytes swf file.

Just makes me angry to see all this wrong information spread around, specially by people who obviously don't have a clue what Flash is about, let alone know how to use it.

Muzak
- Prettier and smaller!????????
  2002-07-15 19:40:49 Tom Hart [Reply]
  
  I'd like to see your example. Can you post the file some place public where we can all look at it for comparison?

Going wireless
2002-04-18 09:42:26 Pete Fairhurst [Reply]

I think the idea that SVG will become the embedded standard in future browsers is very close to the mark. Dynamic gfx have been severely lacking from the (code-based) web, with users of course having to resort to Flash et al for interactive displays.

Now that the advances in DOM and the dynamic "vanilla" web (i.e. W3C standards, not seperate languages e.g. ASP) are coming thick and fast, IMHO it's only a matter of time before SVG explodes onto the scene proper.

Personally, I think that as more and more users "go mobile", a browser-included standard for vector gfx is the way forward; can you imagine how large a Flash plug-in would be for a handheld? Admittedly, it would be scaled to fit, but why should you need to download a plug-in at all? If SVG was supported "in-browser", this would eliminate the necessity for an external download, and would also eliminate the brain ache that is compatibility.

I'm no authority on Flash, nor SVG (perhaps glaringly obvious on both accounts), just a very interested dabbler. I've tried to get into Flash on numerous occaisions, and never had much success (even when working almost entirely in the incredibly patronising ActionScript). This is probably down to the fact that my eye says "GUI" but my brain screams "it's code!".

For me, SVG is a more attractive prospect all round. Roll on integral browser support I say.
- Going wireless
  2002-04-22 03:32:59 Muzak Deezign [Reply]
  
  Flash already excists for handhelds.
  I think it even comes with windows CE, so no need to install it either.
  Your comments make no sense...
  
  Muzak

loading svg
2002-02-18 08:30:59 jamie godin [Reply]

Is there any way to load in the page with some kind of wait graphic? (ie flash)
- loading svg
  2002-02-21 00:56:01 Antoine Quint [Reply]
  
  Hey,
  
  If you are talking about a pre-loader, then it is not part of the basic set of SVG functionalities. However, it can be achieved easily. Have a look at Kevin Lindsey's excellent site http://www.kevlindev.com/dom/progress/. Also, streaming is a requirement for SVG 2.0, yay!
  
  Antoine

Animation static in Opera
2002-02-14 21:31:15 Hedley Finger [Reply]

I viewed the examples in Opera 6.0, build 1010, running on Windows 2000. The layer of cubes appears and when I right-click the image the context menu of Adobe SVG Viewer appears. This applies even to the *.svgz zipped version.
But the cubes do not bounce on mouse-over -- they just lie there.
In Internet Explorer 6.0 the cubes bounce just as in the Flash animation. What do I need to do to get Opera to show the animation correctly?
- Animation static in Opera
  2002-03-13 01:46:59 tom p [Reply]
  
  It seems that there is a bug in Operas Scriptengine in Version 6 again. I tried it with Version 5.12 and it did work.
  Tom
- Animation static in Opera
  2002-02-17 06:58:32 Antoine Quint [Reply]
  
  Hello,
  
  Adobe does not officially support Opera for the time being (see http://www.adobe.com/svg/indepth/faq.html#installother). You can also ask Adobe to support Opera on their feedback form at http://www.adobe.com/svg/feedback/bugreport.html. Sorry I don't have the knowledge to help you :(
  
  Antoine

Good Article but can't be compared to flash as of now.
2002-02-05 20:17:02 Neeraj Kumar [Reply]

Needs a good amount of time and hardwork to make it touch the skies of flash. Although it is helpfull in making smaller documents than flash.
- Good Article but can't be compared to flash as of now.
  2002-02-06 00:52:27 Antoine Quint [Reply]
  
  I understand your concerns, and this is mostly due to the fact that there is no tool as advanced as Macromedia Flash or Adobe LiveMotion that allows SVG export today. However, these should appear soonish as SVG is being embraced by more players in the Graphics industry. But strictly based on SVG's capabilities, it is definitely a strong(er) option when it comes to Web animated vector graphics. The learning curve can only get smoother as tools keep on popping up.
  
  Antoine

Difference with original
2002-02-01 02:44:41 Peter De Keer [Reply]

I just love this article, but I have just a question...
In the original (Flash) version only the upper plane of the cube is sensitive to the mouse movements... I know some people are going to say it's to easy question to answer, but how do I make only the upper plane of the cube sensitive instead of the whole cube??

Thank u for the nicest tutotial about animation around!!!
- Difference with original
  2002-02-01 07:46:25 Antoine Quint [Reply]
  
  Howdy,
  
  There are no easy questions, just questions :). There are different ways you could do that. Basically, what you could do is have two symbols instead of one. The first one would the top of the cube, and the other one the rest of the cube. Then, you would have both <use>d as part of a <g>roup and <animate> the whole <g>roup. It would look roughly like this:
  
  <g id="g1">
  <use xlink:href="#topOfCube" id="top1" />
  <use xlink:href="#restOfCube" />
  <animate begin="top1.mouseover" ... />
  </g>
  
  Hope that helps,
  
  Antoine

Last samples not working
2002-01-30 02:59:16 Daniel Fournier [Reply]

I'm sorry "mon Cher Antoine", but the last samples don't work with Mozilla on Linux and Adobe SVG plugin.

But the article is really interesting.
I must say I'm convinced SVG is THE future of animation graphics and, much more, of user interfaces either on the Web or on desktop applications.

"F�licitations", and waiting your next column.

Daniel
- Last samples not working
  2002-02-01 06:51:13 Antoine Quint [Reply]
  
  Howdy,
  
  Thanks for the praise. I have noticed the same kind of behaviour with Mozilla 0.9.7 on Windoze too. I believe that sometimes Mozilla forgets about the plug-in. Restarting Moz again should get it sorted. At least, it worked on RH7.2 and Mozilla 0.9.7. Remember that the Adobe plug-in on Linux is still beta. Hope that helps,
  
  Antoine

Inaccurate portrayal of Flash/SWF
2002-01-29 13:36:59 Bruce Epstein [Reply]

Bruce: I can understand the author's enthusiasm for SVG, but his constant references to Flash/SWF paired with the inaccurate statements smack of desperation. There is nothing wrong with preaching to the choir, but he picked the wrong Satan.

Article: "However, SWF has its limitations, dynamic publishing being a big one."

Bruce: SWFs can be published dynamically. SWF is just a file format. Macromedia Generator publishes SWFs dynamically, and there are free open-source third-party alternatives to also create SWFs on the fly.

Article: "If you're familiar with the Flash tool, you'll know that you need movie clips to achieve that kind of behavior, which is fairly advanced. SVG animation keeps it simple."

Bruce: Movie Clips are not at all "advanced". They are the basic unit of Flash and everyone who uses Flash uses Movie Clips (and they're easy to use). Flash animation (via a GUI or ActionScript) is much simpler than specifying a coordinate list in XML.

Article: "Once again, if you have any experience with Flash, you will have noticed that it is a frame-based tool, the timeline being graded in frame units. This means that one has to set up a particular frame rate when publishing SWF animation."

Bruce: Yes and no. Yes, Flash is frame-based and yes, you set a target frame rate, but that isn't the whole story. Flash will dynamically alter rendering quality to help achieve the target frame rate. You can also control Flash assets in a time-based manner if, say, you are willing to drop frames. Flash *automatically* uses time-based animation if there is accompanying streaming audio. Otherwise, Flash assumes you don't want to drop frames, and therefore uses frame-based animation.

Regardless, the relevant question is how animations perform. SWF animations perform well in Flash. SVG tools, to my limited knowledge, are not as advanced. If SVG is time-based, but the player drops too many frames, it offers no advantage.

Article: "An SWF authoring tool will have all the frames computed at export time while SVG animation leaves much of the computation work to the SVG player. This often leads to smaller file sizes and higher computation needs from the device. Then again, animation frame computation may not be the most demanding phase of animation, as actual drawing is probably the most demanding."

Bruce: I don't know what he is trying to say here. SWF files are small. The frames are not computed at export time. I'm not sure what he is differentiating between animation and drawing.

Article: "Well, this is quite simply the list of values that will be assigned to our "attributeName", much like keyframes in Flash."

Bruce: Well keyframes are much easier to work with. Again, the author is confusing the SWF format with the Flash authoring environment. SVG is a format. Flash is an authoring tool. The two cannot be meaningfully compared.

Article: "In Macromedia Flash 5, one can specify easing-in and easing-out between two keyframes with a percentage ranging from "-100%" to "100%". Although this is quite a jolly nice control over acceleration, SVG provides a much sweeter mechanism. Instead of having a simple percentage, SVG allows us to describe the speed behavior of an animation interval with a two-point Bezier curve."

Bruce: You can implement any sort of animation, including acceleration and deceleration in ActionScript. The Flash authoring tool offers one simple option, but the full power of ActionScript lets you do whatever you want, including time-based animation.

Article: "As for the animation itself, it looks like we're done. It should look very much like the original SWF version."

Bruce: Which makes one wonder, why bother?

Article: "In fact, Adobe's SVG Viewer on my laptop gives me a much smoother animation than the SWF played in the Flash player."

Bruce: I don't know how he is defining "smoother". You have to compare apples to apples. Flash has at least 3 rendering modes, and he doesn't say what he's using (which quality). Furthermore, who has the SVG Viewer installed? No one. They're going to use/need a browser plugin where performance may be very different. All animations are different. Was he using alpha channels? Did his animation skip frames? What was the target frame rate? What type of machine?

Article: "By the way, the gzipped version (commonly known as SVGZ) of the final animation is only 926 bytes, while the SWF version is 1.29 KB.
Prettier and smaller!"

Bruce: Well, let's not get too excited over 100 bytes. How would file sizes compare in a more realistic case? What about player download size and ubiquity? If I have to download a 1 MB player to save 100 bytes in a file size, it isn't worth it.

Regards,
Bruce Epstein, Editor, O'Reilly's "ActionScript: The Definitive Guide"
- Inaccurate portrayal of Flash/SWF
  2002-02-01 04:14:40 Robin Berjon [Reply]
  
  I'm not addressing all your points here because I find that some are not relevant to the comparison.
  
  Bruce: "SWFs can be published dynamically. SWF is just a file format. Macromedia Generator publishes SWFs dynamically, and there are free open-source third-party alternatives to also create SWFs on the fly."
  
  Robin: yes, but publishing SWF is a true pain in the ass, and requires specialized software. Publishing XML is trivial and you can use whatever tool you're used to for dynamic content, be it advanced XML software or a simple CGI script that just prints out the content. Even SSI will work... As someone that has published dynamic content in both formats, I find the author's point to hit the nail right on there. Dynamic publishing is clearly a place in which SVG is superior to SWF.
  
  Bruce: Flash animation (via a GUI or ActionScript) is much simpler than specifying a coordinate list in XML.
  
  Robin: I disagree that ActionScript is "much simpler than XML". Comparing a GUI to typing is obviously besides the point.
  
  Bruce: You can implement any sort of animation, including acceleration and deceleration in ActionScript.
  
  Robin: yes, but you'd have to implement a spline equivalent yourself, which wouldn't be quite as elegant a solution.
  
  Article: "As for the animation itself, it looks like we're done. It should look very much like the original SWF version."
  
  Bruce: Which makes one wonder, why bother?
  
  Robin: Because 1) there are too many people that have misconceptions about SVG thinking that it can't do all that SWF does, so there's a point to make here; 2) collaboration between SWFers and SVGers is encouraged so that they can benefit from each other's experience; 3) a number of people are thinking about porting from SWF to SVG because it solves their problems better, showing an example helps; 4) SVG has many advantages (hand editing and dynamic generation, CSS and a real DOM being important ones amongst others) and some of us wouldn't mind seeing SWF disappear in favour of SVG because it would make the world a simpler, cleaner place, so porting "cool stuff" is important to us.
  
  Bruce: Furthermore, who has the SVG Viewer installed? No one
  
  Robin: you might want to check again. That statement is already FUD today, it'll be even more so as time continues to pass. Latest estimates report circa 110 million viewers distributed. Adobe ships the viewer with all of its software (eg Acrobat Reader). Heh, I even just noticed that the box I'm typing this from has the SVG Viewer but no Flash. Of course, not everyone has it yet, but the user base is growing constantly.
  
  Bruce: Well, let's not get too excited over 100 bytes. How would file sizes compare in a more realistic case? What about player download size and ubiquity? If I have to download a 1 MB player to save 100 bytes in a file size, it isn't worth it.
  
  Robin: In all cases I've done comparison, the file sizes are usually comparable, or slightly in favour of SVG (the fact that it uses gz for its compression and that viewers are required to handle it being yet another advantage as gz is a standard HTTP encoding and there are many ways to gzip on the fly in the case of dynamic content). I believe the author's implied point here was that there is no file-size problem in SVG, contrary to what some misinformed people have been saying.
  - Inaccurate portrayal of Flash/SWF
    2002-02-01 06:48:02 Antoine Quint [Reply]
    
    Bruce: I can understand the author's enthusiasm for SVG, but his constant references to Flash/SWF paired with the inaccurate statements smack of desperation. There is nothing wrong with preaching to the choir, but he picked the wrong Satan.
    
    Antoine: Howdy Bruce, I appreciate a renowned Flash person commenting on the article. I shall go through your points and try to have proper arguments instead of just starting a chapel fight (there is no guarantee I won't fail).
    
    Article: "However, SWF has its limitations, dynamic publishing being a big one."
    
    Bruce: SWFs can be published dynamically. SWF is just a file format. Macromedia Generator publishes SWFs dynamically, and there are free open-source third-party alternatives to also create SWFs on the fly.
    
    Antoine: I did not say SWF could not be published dynamically, I said there were limitations compared to SVG. Most existing dynamic-publishing tool for web contents are capable of generating SVG rather than HTML, including the likes of CGI scripts, ASP, PHP, JSP, Java Servlets and even SSI. In fact, anything that lets you write textual content to a client will allow you SVG publishing. There are toolkits available for SWF (and open-source ones with PHP), but I don't believe their versatility is anything to go by compared to SVG.
    
    Article: "If you're familiar with the Flash tool, you'll know that you need movie clips to achieve that kind of behavior, which is fairly advanced. SVG animation keeps it simple."
    
    Bruce: Movie Clips are not at all "advanced". They are the basic unit of Flash and everyone who uses Flash uses Movie Clips (and they're easy to use). Flash animation (via a GUI or ActionScript) is much simpler than specifying a coordinate list in XML.
    
    Antoine: Maybe Movie Clips are not "advanced" in your world, but it certainly wasn't the simplest approach to me when I started out Flash. You are a Flash hot shot but some people do not necessarily have the same kind of knowledge, and I believe that anything that goes beyond a simple timeline-based animation is "fairly advanced". Also, I don't believe SVG users have to "specify coordinates in XML" to create animations, they could just use an authoring tool. I know the market is still a baby but there sure is a lot to expect when you have a look at Jasc's WebDraw and what we can expect from Adobe. However, I believe it can be beneficient for some people to know how SVG works internally rather than just pushing a few GUI buttons here and there. It all depends on what you want from your work.
    
    Article: "Once again, if you have any experience with Flash, you will have noticed that it is a frame-based tool, the timeline being graded in frame units. This means that one has to set up a particular frame rate when publishing SWF animation."
    
    Bruce: Yes and no. Yes, Flash is frame-based and yes, you set a target frame rate, but that isn't the whole story. Flash will dynamically alter rendering quality to help achieve the target frame rate. You can also control Flash assets in a time-based manner if, say, you are willing to drop frames. Flash *automatically* uses time-based animation if there is accompanying streaming audio. Otherwise, Flash assumes you don't want to drop frames, and therefore uses frame-based animation.
    
    Regardless, the relevant question is how animations perform. SWF animations perform well in Flash. SVG tools, to my limited knowledge, are not as advanced. If SVG is time-based, but the player drops too many frames, it offers no advantage.
    
    Antoine: How can you drop frames when they never existed in a formal manner? There is no frame concept in declarative (ie. non-scripted) SVG Animation.
    
    Article: "An SWF authoring tool will have all the frames computed at export time while SVG animation leaves much of the computation work to the SVG player. This often leads to smaller file sizes and higher computation needs from the device. Then again, animation frame computation may not be the most demanding phase of animation, as actual drawing is probably the most demanding."
    
    Bruce: I don't know what he is trying to say here. SWF files are small. The frames are not computed at export time. I'm not sure what he is differentiating between animation and drawing.
    
    Antoine: SWF files are small, but SVG offers smaller file sizes. Frame computation includes computation of transformation matrices for each frame and the likes. Those are the computations that are pre-done by the authoring tool at export time. This way the Flash Player only reads the matrices and applies them at drawing, saving some time. After having run the article's SWF animation through the openSWF parser I noticed that was what the Flash application did.
    
    Article: "Well, this is quite simply the list of values that will be assigned to our "attributeName", much like keyframes in Flash."
    
    Bruce: Well keyframes are much easier to work with. Again, the author is confusing the SWF format with the Flash authoring environment. SVG is a format. Flash is an authoring tool. The two cannot be meaningfully compared.
    
    Antoine: SVG is not just a format! Treat is as a format and you're not getting a portion of what it can allow for. SVG is an XML application, unlike SWF or an SWF tool (like the player which does however boast some over-hyped minimal XML capabilities). It defintely makes sense to compare SVG and Flash. A statement like "Well keyframes are much easier to work with" is wrong too. In an authoring tool, keyframes and the values assigned to "attributeName" would be tightly linked, keyframes being the GUI application rendering of the values (at least in WebDraw).
    
    Article: "In Macromedia Flash 5, one can specify easing-in and easing-out between two keyframes with a percentage ranging from "-100%" to "100%". Although this is quite a jolly nice control over acceleration, SVG provides a much sweeter mechanism. Instead of having a simple percentage, SVG allows us to describe the speed behavior of an animation interval with a two-point Bezier curve."
    
    Bruce: You can implement any sort of animation, including acceleration and deceleration in ActionScript. The Flash authoring tool offers one simple option, but the full power of ActionScript lets you do whatever you want, including time-based animation.
    
    Antoine: I was comparing the native feature-set of SWF and SVG (ie. withouth the scripting). Therefore the statement is correct. There is no way to do this kind of acceleration without ActionScript. Also, it is truly elegant in SVG and it doesn't require you to be an ActionScript dude.
    
    Article: "As for the animation itself, it looks like we're done. It should look very much like the original SWF version."
    
    Bruce: Which makes one wonder, why bother?
    
    Antoine: Helpful comment, that was really worth saying! There are two main reasons to bother. First, Flash people can have a look at how to accomplish relatively simple animations in SVG, with animations they are quite accustomed with (I've seen this type of things around a lot). Second, I hope it clears out some of the misconceptions that SVG is not as powerful as SWF when it comes to animation.
    
    Article: "In fact, Adobe's SVG Viewer on my laptop gives me a much smoother animation than the SWF played in the Flash player."
    
    Bruce: I don't know how he is defining "smoother". You have to compare apples to apples. Flash has at least 3 rendering modes, and he doesn't say what he's using (which quality). Furthermore, who has the SVG Viewer installed? No one. They're going to use/need a browser plugin where performance may be very different. All animations are different. Was he using alpha channels? Did his animation skip frames? What was the target frame rate? What type of machine?
    
    Antoine: I am still hesitating between three definitions of smooth here (from Merriam-Webster): "free from difficulties or impediments", "even and uninterrupted in flow or flight" and "excessively and often artfully suave". Pick the one you prefer. I used the default rendering mode from Macromedia Flash 5 (the highest) and used the default for Adobe's SVG Viewer 3 (high def too). Then I believe I compared apples to apples. Sorry for not making that clearer, you must know that it is not possible to always be exhaustive in an article.
    
    As to the viewer, why do you have to go ahead and make such a bold, uninformed and quite silly statemenent like "Furthermore, who has the SVG Viewer installed? No one."? While it is not as wide-spread as Macromedia's Flash Player, it has been shipped for more than a year with a long list of Adobe products, and most noteworthy Acrobat Reader 5. Latest estimates had distribution at about 100,000,000, which is not so bad (it's just a bit more than "no one"). Your other comments are I believe just the result of an agressive rant so I'll just skip them (although I could point out quickly that all types of animations render equivalent in both players, and often better in Adobe SVG Viewer).
    
    Article: "By the way, the gzipped version (commonly known as SVGZ) of the final animation is only 926 bytes, while the SWF version is 1.29 KB.
    Prettier and smaller!"
    
    Bruce: Well, let's not get too excited over 100 bytes. How would file sizes compare in a more realistic case? What about player download size and ubiquity? If I have to download a 1 MB player to save 100 bytes in a file size, it isn't worth it.
    
    Antoine: Oh boy, another helpful comment, thanks. I thought we were comparing technologies here. Would there be just a slight chance that people get to see a few animations without having to re-download the plug-in? Also, the file size difference here is actually 300 bytes and the SVG was not well-optimized. In fact, the bigger the animations become and the bigger the weight difference is between SWF and compressed SVG. I've got some 60k SWF animations that are twice as big as their SVG equivalent. An average of weight differences shows a 30% difference between SVGz and SWF. So for large pieces of work I believe the plug-in download is not such an overhead, especially now that high-speed internet connections are more common. Anyhow, to keep it plain and simple, there are just things that you can't do with SWF and that you can with SVG and that should prove valuable enough for people to download an argueably large plug-in.
    
    Hope my next instalments will encourage you to take a closer look at SVG, I shall cover DOM scripting shorlt (you ought to dig that).
    
    Antoine
    - Inaccurate portrayal of Flash/SWF
      2002-02-17 17:29:47 John Silva [Reply]
      
      Here's another user who ONLY has the SVG plugin installed NOT Macromedia Flash ! I have resisted downloading the Flash plugin because it is PROPRIETARY (albeit 'de-facto') and usually the content distributed with it is marketing hype that I prefer to do without!
      
      I DID install the SVG plugin and hope someday that SVG will be a standard part of the browser (Netscape ;-) so that I do NOT have to download plugins like Flash or SVG. Once the authoring tools allow 'save to SVG' instead of only Flash, the change will start! As Antoine mentions in his response, add to it the fact that SVG is XML and can be access via the DOM (i.e. web standard) and JavaScript, there are more powerful things waiting for us who want more than just marketing 'pretty pictures' in vector graphic content!
      Also, as Antione mentioned, the capability to dynamically create SVG via [web] server side componentry like Servlets/JSP/ASP/PHP/etc. will allow non-graphic designers to create nice, small graphics for web consumers. My current favorite is the work done by SchemaSoft (Catwalk) on graphical stylesheets that leverage the power of another XML 'dialet', XSLT, to produce SVG dynamically in a non-procedural way!
      
      I guess the point is that SVG opens up vector graphics to NOT just the graphics designers of the world. It seems to me that SVG and the kinds of tools exemplified by Catwalk, will bring this capability to web developers (and programmers)! That, I believe, is NOT the target audience for Flash! [Put another way; I'm a developer and being developing web pages/sites since 1992, but have never used Flash, but I'm expecting to use SVG!]

Does not work with my IE6
2002-01-27 17:53:26 Patrick Nestor [Reply]

I get a message in the status bar that I am missing parameters and my svg file only views partially.I see only one side of the cube.The animation does work, but I only see a partial cube.
Thanks for the article and keep up the good work in promoting SVG technology.
patrick n
- Does not work with my IE6
  2002-01-28 15:30:14 Antoine Quint [Reply]
  
  Howdy Patrick,
  
  This is odd as I have tried the examples with IE 6, Netscape 4 and Mozilla 0.9.7 all on win2k and had no problem? What version of the Adobe SVG Viewer are you running, is it the final build (76) of release 3.0? Anyhow, thanks for looking the article up!
  
  Antoine

great article.
2002-01-26 22:19:40 benjamin moss [Reply]

Are there any SVG animation tools out at present?

i look forward to the next installment :]
- great article.
  2002-01-29 03:57:19 Antoine Quint [Reply]
  
  Howdy,
  
  Well, I believe the last section of this article ("Wrapping it all up") should answer your question!
  
  Antoine

Embbeding the SVG Examples
2002-01-24 16:52:15 Alan Carlyle [Reply]

Exerlent article!!
Good to see SVG get the coverage it deservers.

One point, why didn't you embed the SVG examples in the page so the can be viewed and printed as a whole document? After all this is what SVG is for.

I noticed that another vector graphics plugin was embeded in this way. :-)
- Embbeding the SVG Examples
  2002-01-25 02:40:45 Antoine Quint [Reply]
  
  Howdy,
  
  Not having the SVGs embedded inline was a deliberate choice. I guess I was under the influence of how the W3C SVG spec was made. I think it is clearer that way and some people might not be too keen on having the SVG displayed inline. Also, I just despise the <embed> tag, and since that is the only one Netscape knows I'd rather put a link. Sorry about that, but I like it better that way. Thanks for the praise anyway!
  
  Antoine

Cannot view SVG -- add MIME type to server
2002-01-24 07:30:15 Peter Herndon [Reply]

I cannot view the SVG as SVG in my browser. I am using Internet Explorer 5.5 with Adobe SVG Viewer 3.0, and I can view SVG at other sites. When I first started working with SVG, I had a similar problem. I was publishing an SVG document using Apache, and I could only view the document as XML fragments. I added the SVG MIME types to the "mime.types" file, and this resolved the problem.

Please check on this, as I'd very much like to be able to view your samples in all their animated glory.

---Peter
- Cannot view SVG -- add MIME type to server
  2002-01-24 14:13:04 Antoine Quint [Reply]
  
  Howdy,
  
  The problem has been settled now, you should be able to view the examples correctly (except for the final gzipped version that is yet to be uploaded). Enjoy!
  
  Antoine