Thomas DeWeese wrote:
> The real win would likely be in using Image I/O to write images. In > particular our PNG encoder is extremely slow (I haven't noticed this > to be a large problem with the decoder but I must admit to not > testing it too much).
I guess there's nothing to help general rasterization (SVG -> BufferedImage)?
A somewhat related question- would it be faster to parse/display SVG in the canvas for documents that refer to external (say gif/jpg) images vs having the image data embedded into the docs as base64? We use a third party app that embeds the images in this way... my (untested) intuition is that external images would be faster.
> In the svg12 branch we already have a code fork for 1.3 vs 1.4 so I > would expect that as development moves to that branch that new > 'features' would be enabled for users on JDK 1.4 such as using Image > I/O for reading images.
Sounds like a logical way to migrate. Maybe some day we will have a Batik 2.0 that breaks away from the Java 1.3 constraints?
> It should be fairly simple for someone to write a ImageTagRegistry > Entry that used Image I/O I haven't done so since I didn't think it > warranted introducing the split for jdk 1.4.
OK I did not know about this API, I will have a look. Thanks!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
