First, I would like to thank you for the links you provided me. :) --- In [email protected], "Andreas Neumann" <[EMAIL PROTECTED]> wrote: > Hi Joseph, > > http://www.carto.net/papers/svg/postgis_geturl/ has a listing of > possible optimizations at the bottom of the tutorial. > http://www.svgopen.org/2002/papers/isakowski_neumann__svg_for_interactive_topographic_maps/index.html
> has a section on "code optimization". > > As you mentioned yourself, performance is not only about filesize. > It also depends on the implementation and the underlying XML parser. > To get more info about that you would have to contact the authors of > the implementation, f.e. you could ask at the batik list or contact > the Adobe people. What you explained above is good to be mentioned but then I have a problem I think! How can I make it possible to have a general optimisation mechanism that does not depend on any particular "rendering implementation" since we have different authors with different rendering implementations. Am I right or is there something that I have missed?! > > In my own experience with map data, it is key to reduce the number > of elements in the DOM. Maintaining the DOM is memory and computing > expensive and keeping the number of elements low, helps. For example > if you represent an island with lots of closed, disjunct polygons it > is better to represent this island by one single path-element with > several "M"ovetos than creating several <path/> elements and > grouping them. I once came across this while processing > Navteq/Teleatlas data that was extremely segmented. I first > de-segmentized this data and got much better performance. > > Another thing is to reduce accuracy. There f.e. is no use in > representing data with 8 decimal places if the base unit is a meter > and accuracy is about 10 meters. Also, reducing the number of > vertices helps. Many GIS or graphics software have simplification > and smoothing functionality. > > In cartography, f.e. one good spline curve can replace a dozen or > more single vertices and it even looks better when zooming in. All the things you have mentioned above, I have actually done during my academic year here in Oxford. The good thing is that, all the bove does actually optimise the SVG file somehow but the problem remains if we have animations etc.. I have used XSLT to the all the following. I tried to optimize SVG paths by converting to relative or absolute, converting lines to horizontal or vertical lines when appropriate, C and Q to S and T shorthands where appropriate, reduce accuracy of path coordinates, simplifying a curve by converting cubic splines to quadratics or lines where appropriate. > > I also made the experience that using a lot of <symbol /> and > <use /> elements slowed down the Adobe viewer but worked well in > other viewers. This must be an implementation issue and probably > depends on how the DOM is maintained and the XML parsed. > Again, this actually will give me a problem. What am I going to concentrate at? What implementation? Again, can I make it fit all implementations? What do you think? I don't want my optmisation to depend on one implementation or covering all implementations which then it might give problems!? > Hope this helped a bit to get started. I would be very much > interested in your results. Please publish them if you make > progress. > It did help, thanks alot. It gave me ideas. I will be coming back here giving results of my dissertation. I will let you know :) Hope this discussion will carry on since it does help me with the work. > Good luck with your work, > Andreas Thank you Joseph ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
