Q&D Timing comparisons for two new SVG browsers -- Chrome and i-pod

What a fun couple of weeks for SVG -- two relatively important companies (Apple and Google) introduced SVG support in new areas -- and a conference bristling with enthusiasm! It looks like everyone important now has SVG support (apologies if I missed anyone).

I got some time finally to do some quick testing of SVG in i-phone and Chrome. (and Opera/Mac and Safari/Mac while I was at it).

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.

Now, using the methodologies 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.

David

here are the results (Yes, I still use tables for layout, as I am very old)


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
 <title>Untitled</title>
 <style>
 td.thead{text-align:center; }
 </style>
</head>

<body>
<table cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
    <td colspan="10" class="thead">Seconds to build and render 50 objects iteratively (median of three trials)</td>
</tr>
<tr>
    <td></td>
    <td>Chrome/Win</td>
 <td>Firefox/Win</td>
    <td>IE/ASV</td>
 <td>Opera/MacB</td>
    <td>Opera/Win</td>
    <td>Saf/Ipod</td>
 <td>Saf/MacB</td>
    <td>Saf/Win</td>
</tr>
<tr>
    <td>path</td>
    <td>.55&#177;.04</td>
    <td>1.65&#177;.2</td>
    <td>.84&#177;.09</td>
    <td>1.23&#177;.15</td>
    <td>1.05&#177;.06</td>
 <td>10.4&#177;1.5</td>
    <td>.55&#177;.01</td>
    <td>.78&#177;.01</td>
</tr>
<tr>
    <td>ellipse</td>
    <td>.51&#177;.04</td>
    <td>.58&#177;.02</td>
    <td>.79&#177;.09</td>
    <td>.57&#177;.02</td>
    <td>.84&#177;.04</td>
 <td>6.7&#177;2.1</td>
    <td>.54&#177;.01</td>
    <td>.79&#177;.05</td>
</tr>
</tbody>
</table>
FF/Win -- 3.01<br>
Chrome -- 0.2.149.29<br>
Saf/Win/Mac -- 3.1.2<br>
IE/ASV -- 7.0/3.03<br>
Saf/Ipod -- 2.1<br>
Opera -- 9.5<br>


</body>
</html>

Received on Saturday, 13 September 2008 18:24:18 UTC