SVG memory footprint for a complicated page

I have a design that calls for a large number of small bar graphs (sparkline size). A typical page could easily have 60+ graphs showing 100+ datapoints per graph. Would the in-browser memory footprint of something like that be prohibitive? I could also go with a server-side renderer that outputs pngs, but it seems much more could be done with SVG.

Other considerations: The SVG will likely be turned into V开发者_如何学PythonML for IE by Rapheal.js. So the memory footprint over there needs to be reasonable as well.

Any help, or methodology for finding a good answer is appreciated.

The quantity of svg elements you describe could certainly pose a problem in terms of memory consumption.

As opposed to the canvas element, SVG requires the browser to maintain an object model for all of the represented elements. This object model makes it easy for you to wire an event to the clicking of a particular element. You don't have to keep track of where the square is on the screen, how big it is, scaling, etc. However, this comes at a price of memory requirements, and stands in sharp contrast to the canvas tag, which just worries about what color to paint pixels, and you have to worry about tracking what "object" was clicked.

So, when trying to figure out if performance will be an issue, it's usually wise to start with the lowest common denominator, so-to-speak, in terms of your targeted hardware. Are you targeting mobile devices? Are you targeting laptops and desktops?

Once you have an answer to that question, build out a dummy application targeted at that hardware that uses one dummy graph (100 data points) over and over again 60 times. Build just enough so you can interact with the display in a way that mirrors how your users will interact with it (if you want users to be able to slide the graphs around, that should be included, etc.)

Using that dummed-down prototype, now try using the basic interaction and if the performance meets your requirements (i.e., the expectations of your application's audience.)

In terms of performance enhancements to an app of this nature, I'd suggest using a combination of ajax and svg. I'd generate thumbnails of the graphs (using SVG, they'd be much smaller footprints thanks to reduced detail), and as a user decides to get more detail, I'd use ajax to grab a more detailed SVG representation of that particular graph.

Enjoy building your app :)

Love Adam's idea of using a PNG stand-in for the SVG sparklines and pulling down SVG on an as-needed basis. These could easily be rendered on the server-side using the same SVG source fed into a library like librsvg or maybe Cairo.

If you're looking for something that uses canvas (with automatic workarounds for IE) take a look at the jQuery Sparklines library, it may already do everything you need.

Normalizing your data is key. In most instances, 100 data points are not needed nor noticeable to the human eye in a sparkline that's 50px wide. Use data normalization to reduce from 100 points to 5, which is easier on the eyes and more performant.

Server-side sparkline image sprites will tend to outperform front-end SVG/Canvas-generated sparklines when you have large numbers of them.

Here's a fast, server-side sparkline solution in Java that uses excellent PNG compression:

https://github.com/AnthumChris/anthum-sparkline