You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Lukasz Matuszczak <l....@atrem.pl> on 2005/07/08 08:00:50 UTC
caching mechanisms - how to speed up batik?
Hello,
I'm interested in cache mechanisms implemented in Batik. I would like to know
what solutions are available now, and how can I extend them.
The users of my application use about 100 diagrams which are based on about 10
SVG documents. The change between different screens based on the same document
is for example different label, or different data which is changing dynamically.
The user can open or close any document in the same or different tab at any time
(so I can have many JSVGCanvases sometimes based on the document from the same
URI). My problem is that any time he/she does it I read the whole document from
a file, then i parse it to a DOM tree, then I put it in a JSVGCanvas component
which generates and renders a GVT tree.
1. It would be nice to cache DOM tree somehow.
I figured out that the DocumentLoader uses some kind of uri cache, but as far as
I understand loadSVGDocument method in JSVGComponent, the new DocumentLoader is
used any time I use setURI method. Moreover the cache is not shared among many
JSVGCanvas instances.
This kind of cache could be really nice, but how could I use it when my document
is changing dynamically on SVGScreen. I have thought about puting document in
its begining state in cache, and then get it out of cache cloning the DOM tree.
But would it be faster then parsing document from a file?
2. Could you give me any hints how could I cache font definitions available in
svg files?
The font definitions are often the big part of my svg documents so I would like
to cache them (SVGGVTFont objects?), but I have no idea how to integrate such
kind of cache with batik.
Because, as far as I understand, the text rendering mechanism is the slowest
part of Batik it would be also great to create some kind of simplified text tag,
less powerful than original one but faster. Any hints how to do it?
3. Would it be possible to serialize DOM or GVT tree somehow, or maybe the whole
JSVGCanvas and put it on the disk?
4. Is there any progress in implementing SVG 1.2 static css hint?
I have problems in splitting my documents in two parts dynamic (transparent
JSVGCanvas) and static, because:
a) The both parts should use the same definitions of gradients, fonts or css
styles. So how to do it effectively (memory usage is important)?
b) To implement such layers I have to use two JSVGCanvas instances, so I cannot
use SVGScrollPane with them and I have two big image buffers.
Regards,
Lukasz Matuszczak
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG Print
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> I'm also quite interested in SVG Print. I haven't see much energy behind
> the idea recently, though. IMO the two year old working draft would
> still need a few improvements. I don't know about any printer
> manufacturers supporting SVG though I think Canon is (or was) the
> driving force behind this.
HP also made some non-trivial contributions.
> With printers starting to support BlueTooth this might become more
> interesting especially when printing from mobile devices.
Gosh I hope so, but everyone seems to be running down the
XHTML Print path which is ok for really dumb generators who just
want to get a page of text out but for anything with real
graphical content (or really anything with any structure to it)
XHTML/CSS Basic is a total mine field (just look at the web).
> It should be relatively easy to get SVG Print functionality into Batik
> with indirect printing through PostScript as there is a PostScript
> Transcoder available (coming from the FOP project). Otherwise, you can
> simply print to JPS (Java Printing System) by letting Batik render the
> SVG to a Graphics2D instance. The elements defined by SVGP should be
> easy to add.
Yes adding print support to the transcoders should be fairly
trivial (mostly just a matter of adding a loop and 'faking' an
appropriate SVG element for the page in question). Adding it to
Squiggle (the browser) would be a bit tricker, as you would probably
want the ability to show thumbnails and traverse links etc...
Still I don't think it would be a huge task, it strikes me as
a sort of Collage 'Final Project' type thing - about a semesters
worth of work.
> Anyway, SVGP is mostly a hobby for me...
Yes.
> On 16.07.2005 23:10:06 Gregory wrote:
>
>>I am also very interested in SVGP.
>>
>>Do you know if some printer manufacturers plan to
>>implement SVGP for their printers either natively or
>>indirectly (something like SVG -> Postscript ->
>>print)?
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
SVG Print (was: Re: Extensions samples)
Posted by Jeremias Maerki <de...@greenmail.ch>.
I'm also quite interested in SVG Print. I haven't see much energy behind
the idea recently, though. IMO the two year old working draft would
still need a few improvements. I don't know about any printer
manufacturers supporting SVG though I think Canon is (or was) the
driving force behind this. With printers starting to support BlueTooth
this might become more interesting especially when printing from mobile
devices.
It should be relatively easy to get SVG Print functionality into Batik
with indirect printing through PostScript as there is a PostScript
Transcoder available (coming from the FOP project). Otherwise, you can
simply print to JPS (Java Printing System) by letting Batik render the
SVG to a Graphics2D instance. The elements defined by SVGP should be
easy to add.
Anyway, SVGP is mostly a hobby for me...
On 16.07.2005 23:10:06 Gregory wrote:
> I am also very interested in SVGP.
>
> Do you know if some printer manufacturers plan to
> implement SVGP for their printers either natively or
> indirectly (something like SVG -> Postscript ->
> print)?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Extensions samples
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Gregory,
Gregory wrote:
> for your quick answer and your great work.
> It works fine now.
Thanks and good to hear.
> Except solidColor.svg and solidColor2.svg that only
> show 9 red circles in front of 3 black "waves".
Hmm, I suspect this is because the solid color stuff
was moved under the svg 1.2 support. So the old Batik
namespace elements aren't supported any more.
> I have seen that you are one of the author the SVG
> specification.
I participated in the WG for a number of years, but I
haven't been part of the WG for over two years.
> Have you any idea of when the final specification is
> expected to be released and when batik will implement
> it?
No, the working group has already seriously burned
me twice implementing pieces of the not completed spec.
As a result I probably won't do any significant implementation
work on 1.2 until it is final.
> I am also very interested in SVGP.
See my response to Jeremias about this.
> Do you know if some printer manufacturers plan to
> implement SVGP for their printers either natively or
> indirectly (something like SVG -> Postscript ->
> print)?
The SVG WG member from Cannon said they were interested
in it a number of years ago but I haven't heard anything
since....
>
> --- Thomas DeWeese <Th...@Kodak.com> wrote:
>
>
>>Hi Gregory,
>>
>>Gregory wrote:
>>
>>
>>>In the batik-1.6 dist there are some extension
>>>samples.
>>>
>>>I have tried to view them but squiggle doesn't
>>
>>seem to
>>
>>>take into account the custom tags.
>>
>> You have to use the 'special' ext jar of squiggle
>>(batik-1.6/extensions/batik-squiggle-ext.jar). This
>>just adds the batik-extension.jar to the classpath.
>>This is mostly done to avoid any possible confusion
>>about
>>what is and what is not in the SVG specification.
>>
>>
>>>For example, the flow examples don't show the
>>
>>text,
>>
>>>star.svg only shows circles while I expected some
>>>stars.
>>
>> I should mention that the 1.6 release includes a
>>version
>>of the flow text that was proposed for SVG 1.2
>>(although
>>it seems to have changed in recent drafts) that
>>supports
>>flow into arbitrary regions not just rectangles.
>>
>>
>>>Do you we need to do something special to see the
>>>effect of these tags?
>>
>> See the above
>>
>>
>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>batik-users-unsubscribe@xmlgraphics.apache.org
>>For additional commands, e-mail:
>>batik-users-help@xmlgraphics.apache.org
>>
>>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Extensions samples
Posted by Gregory <de...@yahoo.com>.
Hi,
Thanks for your quick answer and your great work.
It works fine now.
Except solidColor.svg and solidColor2.svg that only
show 9 red circles in front of 3 black "waves".
I have seen that you are one of the author the SVG
specification.
Have you any idea of when the final specification is
expected to be released and when batik will implement
it?
I am also very interested in SVGP.
Do you know if some printer manufacturers plan to
implement SVGP for their printers either natively or
indirectly (something like SVG -> Postscript ->
print)?
--- Thomas DeWeese <Th...@Kodak.com> wrote:
> Hi Gregory,
>
> Gregory wrote:
>
> > In the batik-1.6 dist there are some extension
> > samples.
> >
> > I have tried to view them but squiggle doesn't
> seem to
> > take into account the custom tags.
>
> You have to use the 'special' ext jar of squiggle
> (batik-1.6/extensions/batik-squiggle-ext.jar). This
> just adds the batik-extension.jar to the classpath.
> This is mostly done to avoid any possible confusion
> about
> what is and what is not in the SVG specification.
>
> > For example, the flow examples don't show the
> text,
> > star.svg only shows circles while I expected some
> > stars.
>
> I should mention that the 1.6 release includes a
> version
> of the flow text that was proposed for SVG 1.2
> (although
> it seems to have changed in recent drafts) that
> supports
> flow into arbitrary regions not just rectangles.
>
> > Do you we need to do something special to see the
> > effect of these tags?
>
> See the above
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Extensions samples
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Gregory,
Gregory wrote:
> In the batik-1.6 dist there are some extension
> samples.
>
> I have tried to view them but squiggle doesn't seem to
> take into account the custom tags.
You have to use the 'special' ext jar of squiggle
(batik-1.6/extensions/batik-squiggle-ext.jar). This
just adds the batik-extension.jar to the classpath.
This is mostly done to avoid any possible confusion about
what is and what is not in the SVG specification.
> For example, the flow examples don't show the text,
> star.svg only shows circles while I expected some
> stars.
I should mention that the 1.6 release includes a version
of the flow text that was proposed for SVG 1.2 (although
it seems to have changed in recent drafts) that supports
flow into arbitrary regions not just rectangles.
> Do you we need to do something special to see the
> effect of these tags?
See the above
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Extensions samples
Posted by Gregory <de...@yahoo.com>.
Hi,
In the batik-1.6 dist there are some extension
samples.
I have tried to view them but squiggle doesn't seem to
take into account the custom tags.
For example, the flow examples don't show the text,
star.svg only shows circles while I expected some
stars.
Do you we need to do something special to see the
effect of these tags?
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Transcoding DOM => blank output [SOLVED]
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
On Tue, 2005-07-12 at 19:13 -0700, Gregory wrote:
> I just needed to set the created element namespace to
> the svg namespace.
>
> What confuses me it's that squiggle renders the
> document properly while the transcoder doesn't if I
> don't set the namespace.
If I am not wrong when batik parse the xml source, it build the svg
using appropriate namespace. In contrast when you build the DOM
manually, it is your responsibility to set correct namespace.
Maybe Thomas could provide better clarification on this matter.
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
> --- Gregory <de...@yahoo.com> wrote:
>
> > Hi,
> >
> > I created a very simple SVG DOM (see code above).
> >
> > If I serialize the DOM to a file and view the file
> > with squiggle its looks fine.
> >
> > If I transcode the DOM to a png, tiff or jpeg file,
> > the result has the right dimensions but it's blank.
> >
> > Actually only a transparent layer with the
> > PNGTranscoder, a white layer with the JPGTranscoder
> > and a black layer with the TIFFTranscoder. But in
> > any
> > case I never get the actual drawing.
> >
> > If I build the DOM from an URI instead of from
> > scratch, I get a correct result.
> >
> > What did I missed?
> >
> > --- java code ---
> > public static void main(String[] args) throws
> > Exception
> > {
> > final DOMImplementation impl =
> > SVGDOMImplementation.getDOMImplementation();
> > final String svgNS =
> > SVGDOMImplementation.SVG_NAMESPACE_URI;
> > final Document doc = impl.createDocument(svgNS,
> > "svg", null);
> > final Element root = doc.getDocumentElement();
> > root.setAttribute("width", "504");
> > root.setAttribute("height", "480");
> > final Element rect = doc.createElement("rect");
> > rect.setAttribute("x", "0");
> > rect.setAttribute("y", "0");
> > rect.setAttribute("width", "504");
> > rect.setAttribute("height", "480");
> > rect.setAttribute("fill", "yellow");
> > root.appendChild(rect);
> >
> > // Save the dom to a file for verification
> > final Transformer tr =
> > TransformerFactory.newInstance().newTransformer();
> > tr.transform(new DOMSource(doc), new
> > StreamResult("/tmp/out/2.svg"));
> >
> > // The actual rasterization
> > final Transcoder trc = new PNGTranscoder();
> > final int screenDpi = 72;
> > trc.addTranscodingHint(ImageTranscoder.KEY_WIDTH,
> > new Float(504));
> >
> >
> trc.addTranscodingHint(ImageTranscoder.KEY_PIXEL_UNIT_TO_MILLIMETER,
> > new Float(25.4f / screenDpi));
> > final TranscoderInput in = new
> > TranscoderInput(doc);
> > final TranscoderOutput out = new
> > TranscoderOutput(new BufferedOutputStream(new
> > FileOutputStream("/tmp/out/out.png")));
> > trc.transcode(in, out);
> > out.getOutputStream().flush();
> > out.getOutputStream().close();
> > System.out.println("done");
> > }
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Transcoding DOM => blank output [SOLVED]
Posted by Gregory <de...@yahoo.com>.
I just needed to set the created element namespace to
the svg namespace.
What confuses me it's that squiggle renders the
document properly while the transcoder doesn't if I
don't set the namespace.
--- Gregory <de...@yahoo.com> wrote:
> Hi,
>
> I created a very simple SVG DOM (see code above).
>
> If I serialize the DOM to a file and view the file
> with squiggle its looks fine.
>
> If I transcode the DOM to a png, tiff or jpeg file,
> the result has the right dimensions but it's blank.
>
> Actually only a transparent layer with the
> PNGTranscoder, a white layer with the JPGTranscoder
> and a black layer with the TIFFTranscoder. But in
> any
> case I never get the actual drawing.
>
> If I build the DOM from an URI instead of from
> scratch, I get a correct result.
>
> What did I missed?
>
> --- java code ---
> public static void main(String[] args) throws
> Exception
> {
> final DOMImplementation impl =
> SVGDOMImplementation.getDOMImplementation();
> final String svgNS =
> SVGDOMImplementation.SVG_NAMESPACE_URI;
> final Document doc = impl.createDocument(svgNS,
> "svg", null);
> final Element root = doc.getDocumentElement();
> root.setAttribute("width", "504");
> root.setAttribute("height", "480");
> final Element rect = doc.createElement("rect");
> rect.setAttribute("x", "0");
> rect.setAttribute("y", "0");
> rect.setAttribute("width", "504");
> rect.setAttribute("height", "480");
> rect.setAttribute("fill", "yellow");
> root.appendChild(rect);
>
> // Save the dom to a file for verification
> final Transformer tr =
> TransformerFactory.newInstance().newTransformer();
> tr.transform(new DOMSource(doc), new
> StreamResult("/tmp/out/2.svg"));
>
> // The actual rasterization
> final Transcoder trc = new PNGTranscoder();
> final int screenDpi = 72;
> trc.addTranscodingHint(ImageTranscoder.KEY_WIDTH,
> new Float(504));
>
>
trc.addTranscodingHint(ImageTranscoder.KEY_PIXEL_UNIT_TO_MILLIMETER,
> new Float(25.4f / screenDpi));
> final TranscoderInput in = new
> TranscoderInput(doc);
> final TranscoderOutput out = new
> TranscoderOutput(new BufferedOutputStream(new
> FileOutputStream("/tmp/out/out.png")));
> trc.transcode(in, out);
> out.getOutputStream().flush();
> out.getOutputStream().close();
> System.out.println("done");
> }
>
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Transcoding DOM => blank output
Posted by Gregory <de...@yahoo.com>.
Hi,
I created a very simple SVG DOM (see code above).
If I serialize the DOM to a file and view the file
with squiggle its looks fine.
If I transcode the DOM to a png, tiff or jpeg file,
the result has the right dimensions but it's blank.
Actually only a transparent layer with the
PNGTranscoder, a white layer with the JPGTranscoder
and a black layer with the TIFFTranscoder. But in any
case I never get the actual drawing.
If I build the DOM from an URI instead of from
scratch, I get a correct result.
What did I missed?
--- java code ---
public static void main(String[] args) throws
Exception
{
final DOMImplementation impl =
SVGDOMImplementation.getDOMImplementation();
final String svgNS =
SVGDOMImplementation.SVG_NAMESPACE_URI;
final Document doc = impl.createDocument(svgNS,
"svg", null);
final Element root = doc.getDocumentElement();
root.setAttribute("width", "504");
root.setAttribute("height", "480");
final Element rect = doc.createElement("rect");
rect.setAttribute("x", "0");
rect.setAttribute("y", "0");
rect.setAttribute("width", "504");
rect.setAttribute("height", "480");
rect.setAttribute("fill", "yellow");
root.appendChild(rect);
// Save the dom to a file for verification
final Transformer tr =
TransformerFactory.newInstance().newTransformer();
tr.transform(new DOMSource(doc), new
StreamResult("/tmp/out/2.svg"));
// The actual rasterization
final Transcoder trc = new PNGTranscoder();
final int screenDpi = 72;
trc.addTranscodingHint(ImageTranscoder.KEY_WIDTH,
new Float(504));
trc.addTranscodingHint(ImageTranscoder.KEY_PIXEL_UNIT_TO_MILLIMETER,
new Float(25.4f / screenDpi));
final TranscoderInput in = new TranscoderInput(doc);
final TranscoderOutput out = new
TranscoderOutput(new BufferedOutputStream(new
FileOutputStream("/tmp/out/out.png")));
trc.transcode(in, out);
out.getOutputStream().flush();
out.getOutputStream().close();
System.out.println("done");
}
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: caching mechanisms - how to speed up batik?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Lukasz,
Lukasz Matuszczak wrote:
> I'm interested in cache mechanisms implemented in Batik.
>
> 1. It would be nice to cache DOM tree somehow.
> I figured out that the DocumentLoader uses some kind of uri cache, but
> as far as I understand loadSVGDocument method in JSVGComponent, the new
> DocumentLoader is used any time I use setURI method. Moreover the cache
> is not shared among many JSVGCanvas instances.
> This kind of cache could be really nice, but how could I use it when my
> document is changing dynamically on SVGScreen. I have thought about
> puting document in its begining state in cache, and then get it out of
> cache cloning the DOM tree.
You should should be able to create your own instance of the
DocumentLoader class and fetch all of your 'base' documents from
it for all of your canvases. You should probably consider
extending the JSVGCanvas so you can provide the DocumentLoader
instance it should use (probably as a second argument to
setSVGDocument).
> But would it be faster then parsing document from a file?
Yes cloning a DOM should be _much_ faster than reading.
Of course reading _and_ cloning will be slower than just reading...
One neat thing to do would be to have a DOM mutation event listener
on the root of the Document in the Cache (using capture not bubble)
then if a change is about to happen clone the tree and replace the
cache copy with the clone. This would avoid cloning everything
(as many 'reference' documents - fonts, symbols, are never touched).
> 2. Could you give me any hints how could I cache font definitions
> available in svg files?
They already are. The FontFamilyResolver maps family names
to a GVTFontFamily, this is done globally for a JVM instance
(CSS gives you leeway to do this I believe - font family names
are supposed to be unique).
> The font definitions are often the big part of my svg documents so I
> would like to cache them (SVGGVTFont objects?), but I have no idea how
> to integrate such kind of cache with batik.
You might instrument the code to make sure it is working as
expected.
> Because, as far as I understand, the text rendering mechanism is the
> slowest part of Batik it would be also great to create some kind of
> simplified text tag, less powerful than original one but faster. Any
> hints how to do it?
Well you can always create your own extension (in a custom
namespace of course). You will then need to create your own
GVT GraphicsNode. If you don't care about complex things creating
one built around 'drawString' should be fairly simple (although
bounds calcs might be a little tricky). There are some examples
of simple extensions in sources/org/apache/batik/extension/svg.
Ideally the current text stuff could detect if it was a 'simple'
text element or not and use the proper type of text node.
> 3. Would it be possible to serialize DOM or GVT tree somehow, or maybe
> the whole JSVGCanvas and put it on the disk?
Well XML is the serial version of DOM ;)
More seriously currently Batik is not set up for this at all.
I don't know how much trouble this would be to add.
> 4. Is there any progress in implementing SVG 1.2 static css hint?
I haven't been working on it lately.
> I have problems in splitting my documents in two parts dynamic
> (transparent JSVGCanvas) and static, because:
> a) The both parts should use the same definitions of gradients, fonts or
> css styles. So how to do it effectively (memory usage is important)?
I would move those things into a third document that both reference.
> b) To implement such layers I have to use two JSVGCanvas instances, so I
> cannot use SVGScrollPane with them
Well you have the source to the SVGScrollPane so you might be
able to extend it to manage 'two' canvas's...
> and I have two big image buffers.
Well the 'static' thing won't help this much as there will still be
a big image buffer for the 'static' part of the image.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org