xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: clip-path performance / swapping SVGDocuments
Date Sat, 03 Sep 2005 12:28:55 GMT
Hi Dominik,

Steiner, Dominik wrote:

> 1)       when I clone a  <g>-node (which has a lot of child nodes and is 
> expensive to build and render) buy adding a clip-path attribute to the 
> cloned node, but still the cloned and clipped <g>node when added to 
> another JSVGCanvas seems to take as much time as his unclipped clone. Is 
> there a way to optimize rendering/building with clipped nodes?

    So the rendering actually is optimized as much as it can be (we
check group bounding boxes against the clip region in the SVG element
and prune subtrees based on this).  We can't abbreviate the building of
the Graphics tree based on clipping because, first off we have to parse
and build the geometric info to know that it's clipped and second
even clipped elements can receive events.

    However if you know that an element (or whole subtree) will not
be rendered you can help Batik a lot by setting 'display="none"'
which will omit the building of the graphics tree and consequently
any rendering of that portion of the tree.

> 2)       I want to swap the SVGDocuments from 2 JSVGCanvases. How can I 
> achieve that the JSVGCanvas hasn’t to build the GVT tree again?

    Well Tonny pointed out that if you don't need dynamic stuff you
can use the JGVTComponent and just swap the GVT tree's (that's
more or less what the thumbnail viewer does).

    The other thing you might consider is just swapping the two
canvas's rather than trying to swap the documents they contain.
In theory you should be able to swap the UpdateManager,
bridgeContext, GVT tree, etc.  But I don't think it would be
real clean.

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

View raw message