Andreas and Thomas, Thanks for the comprehensive replies. More than enough suggestions to be getting on with! :)
I think the suggested refinements to make to my code will allow to me render most of what I require anyway. And also, I think we will definitely be following the route whereby if the user does request a graph that requires a number of points that exceeds a set maximum, they will be given a raster image, rather than an SVG Document. Tough luck on them if they don't know how to filter their data! Thanks as always for the advice, Cheers, Dylan. -----Original Message----- From: Andreas Neumann [mailto:[EMAIL PROTECTED] Sent: 21 July 2006 10:56 To: [email protected] Subject: Re: Displaying large number of SVG elements (Memory Handling) Hi Dylan, SVG viewers have their limitation and as far as I know, SVG was never designed to handle huge amounts of data. Of course it would be nice if it could ... Parts of the reason of why it can't handle huge amounts of data are the interactivity and animation features SVG provides. It has to maintain the DOM for all the elements, which is expensive. The threshold value of the number of elements that a viewer can handle varies according to the hardware and the software implementation. It maybe at 10000 elements up to 50000 elements. I never saw a SVG implementation that could handle >50000 elements without performance problems and many viewers already fail with 10000 elements. There might be workarounds, though: * use a clever serverside generation in combination with network requests - if you want to show an overview of your data, just show the most prominent features or aggregate features that are close to each other - if the user zooms in, provide additional graphics or details as an example see our yosemite maps (http://www.carto.net/williams/yosemite/), which works in all SVG full viewers, even if they don't support a large number of elements. Content is generated serverside according to the map extent the user had chosen. If a user zooms in, he gets additional elements and the geometry is more detailed, as he zooms out, geometry is simplified on the server, selected, partially aggregated or we use different datasets. * try to reduce the number of elements. As an example: if several circles share the same attributes/interactivity it might be more efficient to use a path element with lots of "M" moveto commands and use markers to show the circles. If you have lots of path elements, try to aggregate them to viewer path elements. * use elements are usually in particular slow. If you can use rects or circles instead of the use elements, thats in almost all cases more efficient than use elements If you don't need the interactivity, other technologies (e.g. raster graphics) might be more suitable, but as I see, you use the mouse events, so this might not be an option. * finally: if you really need to support such a large number of elements, try to support SVG viewer development either by contributing suggestions to improve the code, contributing code or helping financially by supporting developers. I don't know if that is an option. I produced a document that describes server-client communication for maps and contains suggestions/ideas to improve performance. I don't know if that helps: http://www.carto.net/papers/svg/postgis_geturl_xmlhttprequest/ Andreas Dylan Browne wrote: > > > > > > > Hi, > > > > I guess this is a general question that I'm sure all SVG developers > come across, how to handle an SVG Document that contains a very large > number of SVG Elements. > > > > I've scanned the archives but didn't see anything that relates to my > current issue, that is displaying a large number of elements AND those > elements containing a great deal of information. > > > > For example, as below, this is my code to render a single circle on a > graph, together with it's associated JS etc. None of the information > is redundant, as far as I can see. I was wondering if there is any way > to 'compress' this, if that makes sense. I could conceivably need to > generate 50,000 of these circular points, by which time the Document > is getting bloated and giving outOfMemory errors. (I'm using Batik DOM > to generate my SVG Document in memory and then streaming it to a > browser). > > > > <use fill-opacity="0.2" xmlns:xlink="http://www.w3.org/1999/xlink"; > > > onmousedown="select_group(evt,true,145.94715733333334,445.35867495591333,&ap os;1.0');" > > > stroke="blue" name="1.0" > > onmouseover="selectLabelledLine(evt,'DOSE = > 10.00|IRESP = 42.91|ID = 1.0');select_point(evt);" > > > transform="translate(145.94715733333334,445.35867495591333)scale(5.0)" > > width="5.0%" xlink:show="embed" xlink:type="simple" > fill="blue" > > onmouseup="deselect_group(evt,true,'1.0');" > > height="5.0%" > > > onmouseout="deselectLabelledLine(evt);deselect_point(evt);deselect_group(evt ,true,'1.0');" > > > xlink:href="#circle" xlink:actuate="onLoad"/> > > > > > > Thanks in advance for any advice, > > > > Kind regards, > > Dylan > -- ---------------------------------------------- Andreas Neumann Institute of Cartography ETH Zurich Wolfgang-Paulistrasse 15 CH-8093 Zurich, Switzerland Phone: ++41-44-633 3031, Fax: ++41-44-633 1153 e-mail: [EMAIL PROTECTED] www: http://www.carto.net/neumann/ SVG.Open: http://www.svgopen.org/ Carto.net: http://www.carto.net/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
