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 "Litton, Tom - CEPM" <To...@cepm-us.com> on 2005/05/25 00:16:35 UTC
improving the pdf transcoder performance
The transcoder to PDF seems to be a bit slow in our system. It can take up to 25 seconds to do the conversion. Has anyone tried to do performance improvements with this transcoder? Is it documented anywhere?
Are there any transcoding hints that help? Are there any SVG elements that increase the rendering time for this transcoder (or in general) that i should avoid?
Also, I'm only transcoding part of the image. Is there a way and would it be faster to tell the transcoder to process only the part of the image that I want to include in the PDF?
Thanks,
Tom
----------------------------------------------------------------------
The information contained in this transmission is intended only for
the personal and confidential use of the designated recipients named
herein. If the reader of this transmission is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
transmission in error, and that any review, dissemination,
distribution, or copying of this transmission is strictly prohibited.
If you have received this communication in error, please notify the
sender and return and delete the original transmission immediately.
Thank you.
Re: improving the pdf transcoder performance
Posted by Jeremias Maerki <de...@greenmail.ch>.
Now there's some interesting information in there. You say you're using
the print API. Does that mean you actually don't really use the
PDFTranscoder but only the PDFDocumentGraphics2D in conjunction with JPS?
If yes, you have to be aware that the faster text painting routines from
the PDF Transcoder can only be used if Batik controls the painting.
That's because Batik uses some special extensions to the Graphic2D
interface that allows more sophisticated painting operations. Just
printing to a Graphics2D (via JPS) results in even more of the text
being painted as shapes which takes time because these extensions can't
be used. That's probably the reason why you identified
GraphicsNode.paint as time consuming.
If you say that PDFDocument.output() consumes a lot of time then please
make sure that the OutputStream you write the output to is buffered
(decorate with java.io.BufferedOutputStream). I've done some performance
testing on FOP recently where I discovered that the PostScript renderer
is about 50% slower if its OutputStream isn't buffered. On the other
side, it didn't really make a big difference for the PDF output since
most output is buffered in memory buffers anyway, though not with
BufferedOutputStream. But I think it's worth to check.
I'm not sure when the snapshot of FOP was taken for the Batik 1.5
release. There have been certain improvements in that part. I think you
should consider upgrading to 1.6 so it's easier for us to
help you.
On 26.05.2005 05:41:20 Litton, Tom - CEPM wrote:
> I've done some very crude performance testing (basically printing the
> times to the log file), just to get an idea of what is happening.
>
> It seems you were right. Most of the time is spent in the call to
> GraphicsNode.paint, but a non-significant amount of time is spent on the
> call to PDFDocument.output.
>
> Whats stranger is the times vary greatly depending on the destination of
> the file. Emailing the pdf is much quicker then printing it. I'm
> guessing java's print api takes up alot of memory and slows things down?
>
> I'll try to get a hold of better tools (like JProbe).
>
> I hope you find this useful.
>
> By the way, i'm using batik 1.5. It looks like the PDFTranscoder is
> rather old as well (not sure what version of fop it came from).
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: improving the pdf transcoder performance
Posted by Jeremias Maerki <de...@greenmail.ch>.
This is your lucky day. :-) I was feeling like trying to do this. I had
already done it for the (E)PSTranscoder. It was quite easy to adopt the
approach I had taken there.
Here's the CVS commit with the change:
http://marc.theaimsgroup.com/?l=fop-cvs&m=111704879310535&w=2
Documentation:
To create a new page, just call PDFDocumentGraphics2D.nextPage() when a
page is finished. That's it. :-)
Please get back to us with your findings. I wonder if you really manage
to improve the speed. Somehow I doubt it, just by hacking the transcoder
a bit. We'll see. Good luck.
On 25.05.2005 18:31:24 Litton, Tom - CEPM wrote:
> Thanks Jeremias, it does help alot. I'm still having one small problem though.
>
> I'm in the process of modifying the PDFTranscoder to initialize once,
> then write each page. Hopefully that will make things much faster
> (unfortunately it will probably be specific for my application).
> However, i don't see an obvious way of telling the PDFDocumentGraphics2D
> to create another page. Is this possible?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: improving the pdf transcoder performance
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 25.05.2005 00:16:35 Litton, Tom - CEPM wrote:
> The transcoder to PDF seems to be a bit slow in our system. It can take
> up to 25 seconds to do the conversion. Has anyone tried to do
> performance improvements with this transcoder?
Not me, until now it was exclusively about features when I was working
on it. Maybe you could do some profiling to better determine any
optimization potential. How fast can you convert the same SVG to a
bitmap using Batik?
> Is it documented anywhere?
I've tried to scratch together on a Wiki page what was easily
extractable from my brain.
http://wiki.apache.org/xmlgraphics-batik/PdfTranscoder
> Are there any transcoding hints that help? Are there any SVG elements
> that increase the rendering time for this transcoder (or in general)
> that i should avoid?
I've tried to document this on the Wiki page. Generally, text operations
are critical.
> Also, I'm only transcoding part of the image. Is there a way and would
> it be faster to tell the transcoder to process only the part of the
> image that I want to include in the PDF?
I don't know how Batik does that usually (I'm mostly a FOP guy), but I
know there are no special precautions in the PDF Transcoder code to
avoid unnecessary painting operations. Maybe one of the Batik gurus can
shed some more light on this. I don't know if the PDF Transcoder could
do something here to improve the situation.
I hope that helps a bit.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org