Inaccurate portrayal of Flash/SWF
2002-02-01 06:48:02 Antoine Quint
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
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!]
Previous Message
Up
