Rene, You might consider two things about rendering. First is your coordinate space. We used to render our SVG files using coordinates in the millions. This cause a lot of memory to be allocated and much time was spent allocating memory. We scaled back to thousands (i.e. divided everything by 1000) and this sped things up greatly.
Second is if you have hidden elements that you don't want to appear when the display is initially brought up. You might consider hiding things using 'display' attribute instead of the 'visibility' attribute, as display='none' elements are not rendered at all, whereas visibility="hidden" elements are still rendered. Regards, Randy Message from scr <[EMAIL PROTECTED]> received on 05/04/2007 04:33 AM 05/04/2007 04:33 AM scr <[EMAIL PROTECTED]> Please respond to [email protected] Sent by scr <[EMAIL PROTECTED]> To: [email protected] cc: Subject: Re: Caching DOM and GVT to disk Hi Tom, > Do you know what the basic breakdown of time is? I tried to compare the times as you told me: Sample file content is: (unfortunately I cannot optimize it) <path> elements: 1071 <polyline> elements: 13768 <rect> elements: 634 <line> elements: 0 <polygon> elements: 0 <circle> elements: 0 <ellipse> elements: 390 <text> elements: 257 Overall number of important graphic elements: 16120 nothing else was running on the dual core, 2GHZ, -Xmx512m, JRE1.5.0_11 * Squiggle (4 runs, startup and reloads) load: 1281..1547ms building: 1860..3187ms preparation: 594..1469(!) Rendering: 547..1328 total(?): 5047..5671ms What does preparation mean? Is total the sum of these times or more? * My Application: (4 runs, startup and reloads) parsing: 922..1563 symbols: 109..203 gvt tree: 1266..2047 script binding: 448..1391 rendering: 4953..5218 total: 8479..9687 Conclusio: imo, rendering is the bottle neck, right? Now I have to investigate what is wrong with rendering. Do you have any quick hints (was it allready discussed in other forum threads)? >The problem with GVT is that it has some ugly bindings to things >like Fonts that make it complicated to serialize them. As I recoginzed, serializing the plain Java objects (DOM, GVT) isn't possible, because some of the used classes are not Serializeable's (NotSerializableException). >What would a wired SVG file be? Sorry, misstyped: should be "weird SVG files". Thanks Rene thomas.deweese wrote: > > Hi Rene, > > scr <[EMAIL PROTECTED]> wrote on 04/30/2007 09:06:23 AM: > >> My problem now is just the loading of the files (~7s for about 14.000 >> elements), that is the time from opening to the first time user can see > the >> content. > > Do you know what the basic breakdown of time is? Parsing XML, > Building GVT tree, Rendering Prep, actual rendering? The > Batik Squiggle Browser can print this out to the console if you > turn on, Edit->Preferences->General->Print debugging information to > console. > > >> Our goal is to reduce the time < 2s - I'm sure there is a way ;) >> Rendering seems not be a large problem, since elements (static and > dynamic) >> are not very complicated. >> >> Is there a possibility to persist the processed GVT and/or DOM as Java >> Objects to disk and reload it next time? Has anyone tried yet? > > Well the best way to persist DOM to disk is as XML ;) > The problem with GVT is that it has some ugly bindings to things > like Fonts that make it complicated to serialize them. > >> Is there an alternative to this idea (support by batik API)? Or are > there >> other possibilities to increase performance loading such wired SVG files >> which I may have overseen, yet? > > What would a wired SVG file be? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Caching-DOM-and-GVT-to-disk-tf3669525.html#a10319648 Sent from the Batik - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
