So after several months of wondering about IE9s SVG performance, I finally got around to trying it out.
It is absurdly and blindingly fast! Things like http://srufaculty.sru.edu/david.dailey/svg/pattern.svg and some others, where the animation is done with setTimeout("f()", t) where I pushed t down very low because of how slowly it rendered in other browsers, will now have to be re-calibrated to something more realistic. I wrote this particular thing in 2004 and have watched as other browsers slowly caught up with ASV in managing it; I just never was able to see what the timing interval ought to be. Compare it yourself, and I think youll agree. A newer thing from about 2008 http://srufaculty.sru.edu/david.dailey/svg/clipdrag12.svg simply has a more responsive feel. Its a subtle thing and would be hard to quantify though. There are a few things I found that didnt work, beyond the ones anticipated that contain SMIL and filters, but my test suite is now quite large, so that is to be expected. Shortly after Chrome was released and Safari on the i-phone started to display SVG [http://srufaculty.sru.edu/david.dailey/Benchmarks.htm ], I pulled out my timing tests from the SVGOpen 2007: http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGOpen2007.htm . In 2008 I remarked that Chrome was very fast. Times needed to render 50 objects iteratively varied from 10 seconds for paths in i-pod to 0.51 seconds for ellipses in Chrome/Windows. It looks like it is time to do this set of tests again. Paraphrasing Eric Dahlstrom (from http://tech.groups.yahoo.com/group/svg-developers/message/64567 ), some browsers now back off on rendering when they discover they are unable to keep up with a timed loop. This may keep the timing closer to real-time. At any rate, it also means that timing tests such as done in the SVG DOM chamber (http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGChamber99.html ) may, in such cases, give underestimates for the actual time. I think this can compensated for though in a relative sense for cross-browser comparisons, since browsers that dont do that will have very low inter-trial variability as opposed to those that do. At any rate, more extensive investigations would be in order, but Ive just rerun the tests from 2008 including IE9 and my quick and dirty repeat of those (now longitudinal) experiments confirm my general suspicions: These data represent the time needed to render 50 objects (either ellipses or paths) iteratively. (Median of five trials a bit more reliable than the last time I did this) 2011 FF4.0 IE9 Opera11.04 Safari5.04 path .74 .21±.01 .52±.01 .52±.01 ellipse .74±.01 .23±.02 .51±.01 .52±.01 All browsers showed considerable improvements from the 2008 data (though I cant tell how much of this is due to more modern hardware). Chrome no longer allows my test to be run. I fiddled with the code for half an hour to see if I could find a work around for what I deem to be a browser bug (used to work in all browsers including Chrome, no longer works in Chrome) but couldnt find a solution. Maybe they knew I was going to be doing this ;) IE9 is fast for SVG, just like the MS folks told us it would be at SVG Open 2010. If they get into filters and SMIL, those things seem well suited to parallelizing, so theyd likely do well there too. However, I did run some additional comparisons for other kinds of objects and found Safari leading the pack on <text> and IE9 being a bit sluggish there and on <use> tags. It would be fun to dust off the SVG DOM chamber and the related animation chamber (for timing documents packed with <animate> nodes) http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/chamber.html, particularly in light of Erics comments above, and to add a statistical component to test the significance of what appear to be strong browser by type-of-object interactions, but such is not in my immediate future as per my tea leaves. Conclusions: Im anxious to start writing things that will stress browsers a bit more, now that theyve gotten competitive. <replicate> will be an obvious area of experimentation now that I have the horsepower to do it. The boundary between where SVG, on the high end, makes sense and where <canvas>, on the low end makes sense, just moved a bit lower: declarative solutions will usually win out over scripted ones, given the size of the web relative to the number of programmers. Cheers David [Non-text portions of this message have been removed] ------------------------------------ ----- To unsubscribe send a message to: [email protected] -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: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
