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]
