[1] http://srufaculty.sru.edu/david.dailey/svg/groupuse.svg
opera 10.62 : 237 Chrome 6.0 : 211 IE8/asv : 164 FF4.0b6 : 160 Safari 5.0.2 : 74 The above [1] represents a count (I did the counting as my 13 year old daughter watched a timer) of the number of actual screen redraws in one minute of the animation at [1, above] all running under Windows XP. (Yes, dear skeptic, humans can count more than one thing per second with accuracy, though, I confess that 237 per 60 seconds is pushing my own aged limits! And, no, seconds are not a special indivisible atom of time whose innate sensibleness defines the essence of metric time for all species with ten fingers!) . You are welcome to re-run this experiment, but you'd have to get your own daughter. This example illustrates that if one packs enough content into a document, then, even animating a single attribute of a single object (which happens to be reused a few times) can slow browsers down to such an extent that one can actually count the screen redraws (without recourse to using much equipment at all). In the above table (FS=[:\s]*; RS="\n"), bigger numbers are better and Opera is at the top of this list for the first time I started doing such timing tests in preparation for SVG Open 2006 (see http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGOpen2007.htm ) It is interesting that everyone is now playing this game (well unless I overlooked anyone), since, when I started, only IE/ASV and Opera played the svg/smil game and IE/ASV won by almost an order of magnitude. <rant>[2] Anyhow, this is just one highly saturated animation test, but an interesting one... and it is rather pretty. Anecdotally, if we were to measure the number of animatable attributes within the spec that actually succeed in animating, I'd estimate something like the following: Opera 99% IE/ASV 98% FF4. 95% Chrome 85% (too many filter effects are not yet implemented and those tend to have a lot of attributes) Safari 70% Again, this is just anecdotal (and might need a log transform of some sort to make it reliable), though it would take some true fastidiousness to count the number of animateable attributes in the spec. But, if one were to subject one's acid test to an acid test (yes, then we'd have the meta-acid test), then one would be, somehow, less concerned with the N particular tests that individual H happens to formulate, but more with the class of representative tests that attempt to interpret a given spec. We assume that each human has a probability of p of correctly interpreting the spec and that each author has a certain probabily a of correctly writing the spec.... and so forth. At any rate, if we were to take the basic functionality of browsers as they approach instances: not specific pre-constructed instances of web sites, but rather, randomly constructed instances of hypothetical web sites, then already we have overcome what we might call the acid-bias: the tendency of a tester to prove his [3] own hypotheses. The construction of appropriate methodologies which might withstand scientific, philsophical, linguistic, mathematical and common-sense scrutiny is clearly a difficult undertaking. But don't despair. Difficulty is not equivalent to impossibility and the premise of the human endeavor is tha the two are, indeed, not equivalent. The point is that knowing a spec well and knowing browser performance well, one can construct an acid test to prove almost any conclusion one wishes to! Accordingly, how might we objectively evaluate the various acid tests that might emerge as the multi-billion dollar industry sniffing about for the tea leaves of the future of vector graphics swirls through our portfolios? Well, it is complicated. [4] My own impression from having spent a couple of relatively manic person-years playing with SVG is that if we measured the success of SVG's implementation across several browsers, including the ability to perform predictably across highly complex examples (and not just the teensy examples that one finds in the test suite) that browers's ability to handle true "acid tests" in the spirit of Tom Wolfe is likely to be quite different than the hand picked examples of certain popular acid tests. Ultimately, "acid tests" are sort of like IQ tests. There are more good ways to use one's brain than there are people. You are The Expert in thinking like you do; and it is unlikely that any one else will surpass you in that ability. A univariate measure of a multivariate trait is rather destined for misinterpretation when presented without the other dimensions. That all having been said, I have presented above, two different measures (both slightly flawed in methodology) for comparing browsers and their support for SVG/SMIL. Let me offer another that is totally subjective: ASV>Opera>FF>Chrome>Safari This transitive relation applies, when it comes to implementing really complex examples involving compound filters, fonts, clips masks, and animation all intermingled promiscuously in groups of at least two. It will be interesting to see how IE/native SVG compares on basic speed tests with the other browsers. Fortunately I won't have to invent new speed tests to test it, since the same speed tests that worked in 2006 still worked just fine when Safari, Chrome and i-pod all came out with notable changes in performance having taken place over those 4+ years of evaluation. Anyhow, its nice to see the browsers coming along with their declarative animation. Trying to do all important declarative animation within CSS would seem a rather Quixotic endeavor. It merely postpones the inevitable for a few years and allows the entrenched investors to lose bigger shirts. Maybe if CSS started having declarative constructs so that one could write Turing machines in CSS, then it might start to have the power one needs, but it certainly would need, as well, to shed its rectilinear world view to have the sorts of expressive power that one will ultimately need to overcome the millenia of inertia imposed by linear models of textual expression. Why did Ted Nelson call it 'hypertext' after all? <grin> David [2] Now... if a company were putting all their eggs in the <canvas> basket (I think canvas may be a trademark of Deneba systems) and shunning both flashiness and vectors, then one might ask "why does one need to put so many objects (eggs?) in the DOM, even if it is only a shadow DOM?" Why not just use direct drawing through an API and render pixels rather than objects? (sorta like in the very old http://srufaculty.sru.edu/david.dailey/javascript/stringtimer.html but maybe we could re-invent that particular wheel if we thought about it hard enough) . Well, the antagonist might respond with a bit of nanny-nanny-swagger "you figure it out", but this would not be productive. If we use SVG or other techniques to draw scenes, then ultimately those scenes may become populated by agents (those things that use verbs). And those agents' actions may be, at any step or faux pas, doing something interesting, such that we (the putative we who observes all this) may wish to know where (not in the 2D x-y sense but in the sense of the virtual semantic world that has been built) they are, so that other events, agents, and observations may follow. The rich interface that follows the rich GUI (that we all advocate) assumes that things which appear to be things actually behave like things. (Put that in your Design Principles 5.55555 !) </endrant> [3] The HTML WG is replete with examples where the pronoun is uniquely defined as "his" rather than "her". [4] For at least five years, Adobe's SVG Zone with its advice on getters and setters was among the top five hits of the Google searches for "SVG" and "SVG basics." For some years, there were ambiguities in the SVG spec that only recently have become clarified. If an author wrote a document consistent with a spec that had not yet reached recommendation status, and the spec later changes, does that mean that the document is non-comforming? If we know that a browser has deficiencies in some area (and all do) then we may simply load our tests with examples from that area to "prove" the shortcomings of that browser. On the other hand, relying on examples found in the wild is likely to produce all manner of idiosyncratic documents authored at a time of inconsistency in the spec or of widespread misinterpretation of its language. [Non-text portions of this message have been removed] ------------------------------------ ----- To unsubscribe send a message to: svg-developers-unsubscr...@yahoogroups.com -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: svg-developers-dig...@yahoogroups.com svg-developers-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: svg-developers-unsubscr...@yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
