(September 2008)
| Seconds to build and render 50 objects iteratively (median of three trials) | |||||||||
| Chrome/Win | Firefox/Win | IE/ASV | Opera/MacB | Opera/Win | Saf/Ipod | Saf/MacB | Saf/Win | ||
| path | .55±.04 | 1.65±.2 | .84±.09 | 1.23±.15 | 1.05±.06 | 10.4±1.5 | .55±.01 | .78±.01 | |
| ellipse | .51±.04 | .58±.02 | .79±.09 | .57±.02 | .84±.04 | 6.7±2.1 | .54±.01 | .79±.05 | |
- FF/Win -- 3.01
- Chrome -- 0.2.149.29
- Saf/Win/Mac -- 3.1.2
- IE/ASV -- 7.0/3.03
- Saf/Ipod -- 2.1
- Opera -- 9.5
Impressions: i-phone support is about the same as in Safari for Mac/Win in
terms of what works and what
doesn't. Ditto for Chrome, but, there are some bugs (it is a beta after all --
though I couldn't figure out
where to report them). I-pod SVG is slow.
Methodologies: As presented at SVGOpen 2007,
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGOpen2007.htm ,
I timed some things
for various browsers, using the SVG DOM chamber
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2007/SVGChamber98.html.
To make the comparisons easy to perform across a multitude of browsers, I just
looked at two classes of
objects: paths (big random triangles) and circles (little circles at random
locations). These two
objects were representative of the range of browser differences observed in
earlier testing and showed
strong browser-by-objecttype intereactions in the previous work. The DOM
insertion mode was iterative
rather than concurrent (meaning it was controlled by a JavaScript timing loop to
allow rendering to
finish as discussed in the paper
http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.html )
Note: no significance testing was done -- results report median of three trials
(a statistic not known for
its reliability). However, were statistical testing to be done on a greater
number of trials, I will bet a
beer that both main effects and the two-way interaction (browser by content
type) would be significant --
i.e., wearing my hat as a former stat prof: the results are pretty robust. The
reason for the high
variability with large triangles is that different amounts of overlap between
triangles occurs and the
way that certain browsers (notably FF) paint the screen will be expected to vary
as a function of that
randomness in the actual Monte Carlo analysis.
Other impressions: Chrome is quite fast, rivaling Safari in its "native
environment" (MacBook). I-pod
implementation is slow -- as in by integer multiples. Both have a long ways to
go in terms of catching up with
Opera in the extent of the spec actually handled to date.