When we discussed this before I predicted that SVG would reduce server side computation and network bandwidth usage while increasing client side computation, but it's great to see hard numbers Jesse, nice testing there. :) Unfortunately, Bernard is probably right that rrdtool's SVG output currently won't be very consistent between browsers (I don't think very many people use rrdtool SVG output, but I might be able to put some work in to rrdtool to stabilize the SVG output between browsers). The worst problem I think though would be embedding the SVG graphs within an HTML page. That is probably the least consistent thing between browsers: since IE uses the Adobe SVG viewer plugin it needs a different embedding method than Firefox and Opera which have native SVG support. I don't know what Safari is like for SVG support. I think there are a few solutions for abstracting the embed method so that it is browser-independent, but I'm probably not the best person to go to on that since I've never even used SVG embedding except for seeing some tutorials that do it. :)
-Matt SVG graphs Matt Ryan wrote: > > I had heard once that there were browser compatibility issues with SVG > - specifically, that they didn't "work properly" on browsers other > than IE. Perhaps I misunderstood?? > > > > > >>> "Bernard Li" <[EMAIL PROTECTED]> 12/13/07 6:29 PM >>> > Note Matt Chambers originally came up with the idea of using SVG -- I > was just playing with it recently. The frontend template's <img> tags > need to be changed to <embed> tags and also the graph dimensions need > to be specified, for the frontend to be able to display SVGs -- also, > the resulting graphs do not look exactly the same between PNG and SVG > output formats. > > Cheers, > > Bernard > > On 12/13/07, Jesse Becker <[EMAIL PROTECTED]> wrote: > > There was a discussion on IRC recently about PNG vs. SVG output > files. The > > questions we had revolved around how "hard" it is to generate each > format, > > and also decode it as well. Lacking any hard numbers, I decided to > make up > > my own. :) > > > > All tests were run on my laptop, a Pentium-M 1.6GHz box (cpu at > > full-throttle), using rrdtool 1.2.23. The .rrd files came from an > recent > > Ganglia build from the SVN trunk. I copied an .rrd file into a > ramdisk, and > > ran a shell script to benchmark creating and "rendering" PNG and SVG > files. > > > > Creating the files was pretty simple: I just ran these two command a > > thousand times (<grin>): > > > > rrdtool graph /dev/null -a PNG DEF:load=$FILE:sum:AVERAGE > > LINE1:load#ff0000:load > > rrdtool graph /dev/null -a SVG DEF:load=$FILE:sum:AVERAGE > > LINE1:load#ff0000:load > > > > Before the loops, I ran 'dd' on the various input files to make sure > they > > were cached, although since the tests were run on a RAM disk, that > shouldn't > > matter much. > > > > Generating 1,000 PNG files took: > > real 28.57 > > user 21.89 > > sys 2.29 > > > > Generating 1,000 SVG files took much less time: > > real 4.18 > > user 2.34 > > sys 1.03 > > > > This makes quite a bit of sense. Since SVG is just XML, all that really > > needs to be done is wrap some XML stuff around the > datapoints. Making the > > PNG actually requires requires plotting points, and generating the > bitmap. > > > > Once we make the image files, we need to decode them. This is a bit > harder, > > and I couldn't think of a way to easily benchmark Firefox's SVG > rendering > > code. Instead, I used the 'convert' program from ImageMagick to > convert the > > output SVG and PPM files into the next closest thing: a PPM file. I > > realize that this does not tell us anything about browser rending, > and might > > be completely useless. I hope, however, that we can get a rough > idea of how > > "hard" it is for a browser to render an SVG file relative to a PNM file. > > > > Thus, I ran these commands 1,000 times each: > > convert -depth 8 +antialias test.png ppm:- > /dev/null > > convert -depth 8 +antialias test.svg ppm:- > /dev/null > > > > The input files are the files created by rrdtool, with no other > > manipulation. It is interesting to note that the image dimensions > on the > > .svg file are slightly smaller than the png: > > test.png PNG 481x168 481x168+0+0 DirectClass 8-bit 15.2695kb > > test.svg SVG 470x168 470x168+0+0 DirectClass 16-bit 6.28906kb > > > > Also note that the .svg file is less than half the size of the .png. > > > > The numbers > > > > "Decoding" PNG files: > > real 47.50 > > user 37.94 > > sys 3.79 > > > > "Decoding" SVG files: > > real 149.44 > > user 119.52 > > sys 7.34 > > > > So it looks like generating SVG files is clearly faster than PNG > files, by > > about a factor of 10 (User CPU time). On the other hand, "decoding" the > > files with the 'convert' program was clearly slower at SVG files. > > > > The source RRD file and script ar available if anyone wants to play with > > them on their own. > > > > Comments? > > > > -- > > Jesse Becker > > GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2 > ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
