0

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 VML 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.

Matt
  • 2,140
  • 3
  • 16
  • 19
  • This is really easy for you to test, and hard for anyone else to answer because "prohibitive" is subjective. I suggest you crank out a quick test case and determine if it meets your needs or not. – Phrogz Feb 12 '11 at 14:04
  • There are a few issues with this question. First, the memory footprint depends on the browser being used. It also depends on the complexity of the javascript memory structures used to create the plot. Secondly, Raphael doesn't turn SVG into VML, it takes a set of commands to render a vector graphic and structures the graphic inside of the DOM as either SVG or VML. What you probably want to do is create a sample page that creates 60 sparklines on a single page and watch the memory consumption of the browsers that you're interested in. It will almost certainly be MUCH more than PNGs. – Pridkett Feb 15 '11 at 20:25
  • +1 to simply trying it out. Also, as opposed to targeting VML, I would recommend looking into the svg-web library as a way to render SVG in browsers that do not support it natively: http://code.google.com/p/svgweb/ – jbeard4 Feb 16 '11 at 05:03

3 Answers3

4

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 :)

AdamJonR
  • 4,703
  • 2
  • 22
  • 24
  • Thanks for the thoughtful answer. I know nothing substitutes for actually trying it but it's great to get a sanity check before diving in. – Matt Feb 18 '11 at 05:03
1

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.

joshperry
  • 41,167
  • 16
  • 88
  • 103
0

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

anthumchris
  • 8,245
  • 2
  • 28
  • 53