|
|
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 <r.schiessler@xxxxxxxxxxxxxx> 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: batik-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: batik-users-help@xxxxxxxxxxxxxxxxxxxxxx
>
>
>
--
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: batik-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: batik-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
|