Jeremias Maerki wrote:
Seeing your stacktrace and your explanations I can't help but suspect
that maybe the whole AWT font handling could have a strong influence on
performance. If I had free time, I think I'd profile the number of calls
and run time of the Java2DFontMetrics.setFont() method. It could be that
we're changing the font too often while also not reusing font instances
created earlier. I think the logic there is pretty dumb (only one font
is active at one point). I know from my Win32 days that allocating
resources in Windows is not really a cheap operation. Maybe that gets
you some more ideas in which direction to look.
Well, it does look like it's using the same font file since there are no
font constructors or other obviously inefficient things in that stack trace.
However, it seems like almost the whole stack trace could be avoided if
this call cached its results somehow:
org.apache.fop.fonts.Font.getCharWidth(Font.java:231)
(an array of 65536 elements would be enough, but wouldn't be terribly
efficient in terms of memory.)
Daniel
--
Daniel Noll
Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://nuix.com/ Fax: +61 2 9212 6902
This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
