Questions:
You told me about bounding boxes for events. What are exactly?
The choice between display and visibility is really a question of
how often is it rendered compared to how often it is switched. Do all
100 buttons use the same 5 images? I ask because if they do then the
image will be loaded only once, if they all use different images then
while visibility will keep the image around display may cause Batik to
'refetch' the image (which may save memory on the client but will be
very slow generally).
:
All 500 images are different. Only one image of 5 is visible at the same
time and javascript actions switch button images visibility.
What do you mean with refetch image?
Any idea to improve performance?
Thank!
Fabio
> So imagine i have 100 buttons represented by 5 images each for a total
> of 500 images in my svg document.
>
> Only one of button's 5 images is visible and svg switch at runtime
> between these images.
>
> So, as you said, display engine always walk the rendering tree.
>
> I use visibility="hidden" to hide elements.
This is probably the best route.
> Do you think it's faster to create a plain svg document with 500 items
> at the same level, or 100 groups with 5 items each?
I would create 100 groups with 5 items each.
> How is navigation speed of rendering tree bound to the number of
> nested groups? More nesting more speed?
Rendering normally walks the whole tree but stuff like events uses
bounding boxes to limit what sections of the tree need to be walked.
> I imagine also that using display="none" to hide the 4 hidden images
> of button is slower because it recreate rendering tree.
The choice between display and visibility is really a question of
how often is it rendered compared to how often it is switched. Do all
100 buttons use the same 5 images? I ask because if they do then the
image will be loaded only once, if they all use different images then
while visibility will keep the image around display may cause Batik to
'refetch' the image (which may save memory on the client but will be
very slow generally).
>
> -----Messaggio originale-----
> Da: Thomas DeWeese [mailto:[EMAIL PROTECTED]
> Inviato: luned́ 24 novembre 2003 21.25
> A: Batik Users
> Oggetto: Re: performance 2
>
>
> Fabio Biscaro wrote:
>
>
>>I'm trying to optimize svg speed in Batik:
>>
>>Does someone know if is faster to group elements in <g> or if i put
>>all
>>in the svg element?
>
>
> In general it is good to put things in g elements, ideally grouping
> things geometrically rather than in layers. Going to the extreme (1
> element per group) probably isn't a good idea.
>
> So for example it would be _really_ good to put all the elements of
> a button in a group (rather than adding them individually to the
> button's parent). But it may not gain you too much to put symbols in
> a separate group if they are still scattered across the whole canvas.
>
>
>>When via javascript i hide an element does the position of this
>>element
>>matter?
>
>
> How are you hiding an element? If you are doing
> visibility="hidden" then the display engine must still walk the
> rendering tree as children can override this. If you use
> display="none" then the rendering tree is removed - however when/if
> you change it back to display="inline" the rendering tree must then be
> recreated from scratch.
>
> Also moving elements in the DOM tree deletes the old rendering tree
> and creates a new rendering when inserted so this can be expensive.
>
>
>
>>If I get a reference of an object in Javascript via getElementById and
>>then i use that reference is faster than using always getElementById?
>
> (
>
>>I imagine yes!)
>
>
> Yes, keeping the reference around is much much much faster.
>
>
>
>
> ---------------------------------------------------------------------
> 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]
>
>
---------------------------------------------------------------------
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]
