Ognjen, sorry for the late answer. Could you please set the following log level to FINE/DEBUG: org.apache.fop.render.pdf.AbstractImageAdapter
If you get the line "Image returns ICC profile: sRGB, default sRGB=true", your PNG is a normal sRGB bitmap. This will (normally) allow FOP to dump the bitmap data efficiently to the output file. In your case, the encoded color model seems to differ from the original one which is why the ImageEncodingHelper (from XML Graphics Commons) falls back to encoding sRGB data which has to go through color management. And that's what's making the process very slow. Every pixel is converted to sRGB by the color profile associated with the BufferedImage that has been built from the PNG file. But...I cannot reproduce your problem. With all PNGs I've tested I get optimized encoding (Sun Java 6.0_24). Could you please send me your PNG? Maybe there's something peculiar about it. On 18.03.2011 09:20:34 Ognjen Blagojevic wrote: > On 11.3.2011 12:54, Ognjen Blagojevic wrote: > > Having said all this, my proposal is: > > > > 1. if someone can help me to track bug further (remember, 1.6.0_17 was > > working just fine) we could file the bug report to Oracle, or > > 2. we could just add the info in FOP/xmlgraphics docs that color profile > > in PNG images introduces significant slowdown on JDK 1.6.0_18+. > > Ok, since it seems that it is too hard to track this down, I suggest we > add to PNG Graphics page [1] something like: > > "Note: PNG images with color profile are on certain JDKs (most notably > Oracle JDK 6u18+) processed as much as 20 times slower than same images > without color profile. This slowdown is introduced by JDK image > manipulation classes." > > Thoughts? > > -Ognjen > > [1] http://xmlgraphics.apache.org/fop/1.0/graphics.html#png Jeremias Maerki
