Re: R: R: performance 2

[Thomas DeWeese <Th...@Kodak.com>]

Fabio Biscaro wrote:

> Questions:
> 
> You told me about bounding boxes for events. What are exactly?

    When we try to figure out what element to send the event to
we check if the 'clientX/Y' lies within the bounding box of the
element (a bounding box is the smallest rectangle that will hold
the element).

>     The choice between display and visibility is really a question of
> how often is it rendered compared to how often it is switched.
> 
> All 500 images are different. Only one image of 5 is visible at the same
> time and javascript actions switch button images visibility. 

    You definitely want to use visibility in this case.

> What do you mean with refetch image?

    If you use display then the decoded version of the image will
be released and the next time you set display to 'inline' it will
likely get the source image and decode it again.

    Another good idea is if you aren't really changing something
don't change it.  So if you are 'updating' all 100 images but
90 of them end up staying the same you will save lots of time if you
don't touch the 90 that stay the same.

> Any idea to improve performance?

    It sounds to me like you may benefit from providing more memory.
When a JVM get's 'low' in memory it spends a lot of time trying to
find memory it can free up (so in normal operation it is good if the
JVM has ~2x the amount of memory it requires allocated to it).

    I don't really know what operations are being slow for you so
it is hard to say.  Once again a working example to look at can be
extremely helpful.

>>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:Thomas.DeWeese@Kodak.com]
>>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: batik-users-unsubscribe@xml.apache.org
>>For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>>For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org