In this, you speak of the PNG decoder and improving the performance by
using the javax.imageio classes. I am interested in improving the JPEG
rendering time of an SVG. Is it likely that the encode time of the JPEG
encoder may substantially change if I use this encoder?
I am already using JDK 1.4 (and headless operation) to support rendering
within a servlet context. Anyone else already look at this?
Charlie
Mark Vidov wrote:
> Thanks very much for the response. Progress so far:
> 1. The memory settings were -Xms128m -Xmx512m. I can see that memory
> does become a problem as ImageTagRegistry does cache images and my
> application may display many in one session.
> 2. CVS batik is used. Nothing noticeable.
> 3. The all-at-once rendering is used.
> 4. Bypassing the PNG decoder has a large impact. Rendering times were
> reduced to ~1200ms from ~3500ms for these files. This is a high-end
> machine though and I would love to reduce this even more. You
> mentioned gamma correction and offscreen buffer, can you suggest any
> approaches?
> 5. Multi-image is not practical for my application.
>
> Remaining problems:
> 1. Load times are still high with the JDK decoder (it uses
> MediaTracker). I experimented with ImageIO in JDK 1.4 and achieved
> some decent load times.
>
> The code I used for this is to modify handleURL in JDKRegistryEntry to
> support ImageIO if present otherwise fall back to the default method.
> One question I have is why I can't return the loaded BufferedImage
> directly rather than render into the ARGB image? The exception is below.
>
> java.lang.IllegalArgumentException: Number of color/alpha components
> should be 4 but length of bits array is 2
> at java.awt.image.ColorModel.<init>(ColorModel.java:318)
> at
> java.awt.image.ComponentColorModel.<init>(ComponentColorModel.java:256)
> at
> org.apache.batik.ext.awt.image.rendered.AffineRed.fixColorModel(Unknown
> Source)
> at
> org.apache.batik.ext.awt.image.rendered.AffineRed.<init>(Unknown Source)
> at
> org.apache.batik.ext.awt.image.renderable.RedRable.createRendering(Unknown
> Source)
> at
> org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source)
>
> public Filter handleURL(ParsedURL purl, boolean needRawData) {
>
> URL url;
> try {
> url = new URL(purl.toString());
> } catch (MalformedURLException mue) {
> return null;
> }
>
> try
> {
> Class clazz = Class.forName("javax.imageio.ImageIO");
>
> Class[] paramc = new Class[] {URL.class};
> java.lang.reflect.Method m = clazz.getMethod("read", paramc);
> Object[] paramo = new Object[1];
> paramo[0] = url;
> BufferedImage bi = (BufferedImage)m.invoke(null, paramo);
>
> // Using this bi directly results in an exception
> //return new RedRable(GraphicsUtil.wrap(bi));
>
> BufferedImage ri = null;
> ri = new BufferedImage(bi.getWidth(),
> bi.getHeight(),
> BufferedImage.TYPE_INT_ARGB);
> Graphics2D g2d = ri.createGraphics();
> g2d.drawRenderedImage(bi, null);
> g2d.dispose();
> bi = null;
>
> return new RedRable(GraphicsUtil.wrap(ri));
> }
> catch (ClassNotFoundException e0)
> {
> }
> catch (NoSuchMethodException e1)
> {
> }
> catch (IllegalAccessException e2)
> {
> }
> catch (IllegalArgumentException e3)
> {
> }
> catch (java.lang.reflect.InvocationTargetException e4)
> {
> }
>
> Toolkit tk = Toolkit.getDefaultToolkit();
> final Image img = tk.createImage(url);
> if (img == null)
> return null;
>
> RenderedImage ri = loadImage(img);
> if (ri == null)
> return null;
>
> return new RedRable(GraphicsUtil.wrap(ri));
> }
>
> 2. Load and render times often jumped from ~1000ms to over 10000ms. I
> suspect garbage collection or expansion of memory but I really could
> not solve it. The result is that I still cannot achieve consistent and
> acceptable load and render times. Would love to hear suggestions to
> improve memory usage. Maybe turn off the image cache?
>
> 3. Render quality is poor. Adobe does some nice anti-aliasing which
> improves my type of images (engineering drawings with many thin
> lines). Any suggestions on how to improve this or any code I could use
> or modify in the source?
>
>
>
> From: Thomas E Deweese <[EMAIL PROTECTED]>
> Reply-To: "Batik Users" <[EMAIL PROTECTED]>
> To: Batik Users <[EMAIL PROTECTED]>
> Subject: How to improve load time of PNG images?
> Date: Tue, 13 Aug 2002 08:19:06 -0400
>
> >>>>> "MV" == Mark Vidov <[EMAIL PROTECTED]> writes:
>
> MV> What can be done to improve load times of PNG images?
>
> Hard to know without more information on what the bottle neck is.
>
> MV> Can batik be made to use JAI and its native libraries?
>
> It can be, but I don't think this will give you what you want.
>
> MV> Is there a portion of batik that that can be optimized or skipped
> MV> to improve this specific case (eg decoding, scaling, rendering)?
>
> Probably, there are two things that immediately come to mind.
> Gamma correction and our offscreen buffer.
>
> MV> Some details:
>
> MV> I'm using batik to display very simple svgs consisting of an image
> MV> tag and a handful of simple elements (text, rect). The images are
> MV> PNG files, with a typical file being 3200 x 2200 x 4 color (file
> MV> size around 240KB).
>
> Uncompressed that file is ~24MB. This would be a very tight fit
> in the default Java partition of 32MB. You might try giving Java
> something like 128MB this may solve much of your problems.
>
> MV> Load times in squiggle (PIII 1000MHz, GeForce2) are 6-8 seconds
> MV> (GVT build around 3500ms and GVT render around 3500ms). Total load
> MV> time in Adobe SVG is less than 1 second.
>
> MV> Loading and rendering the PNG file in java using
> MV> Graphics.drawImage with scaling (Image.SCALE_FAST) is around 10
> MV> seconds.
>
> Well, considering what we do, so far eveything looks good to me :)
>
> MV> However when I use JDK 1.4.0 with JAI 1.1.1 java rendering drops
> MV> to less than 2 seconds. Using the same JDK and JAI with squiggle
> MV> produces no improvement.
>
> MV> I'm wondering why JAI adds no benefit.
>
> Unless we call JAI directly (which we don't do) having JAI in the
> class path isn't going to do anything. Also for the case you are
> talking about JAI isn't going to do much anyway since all those
> functions are already accellerated by native code in the JDK.
>
> MV> The comparison to Adobe is also shocking. (Adobe also uses some
> MV> smoothing to make my PNG files look much better than in batik.)
>
> MV> This issue is critical and my only alternative seems to be to wrap
> MV> Adobe with JNI (a big pain since Adobe no longer supports its COM
> MV> interfaces).
>
> MV> Any ideas or comments would be much appreciated.
>
> So quick suggestions:
>
> 1) Increase the memory partition (if you haven't already)
> 2) Use CVS Batik (some changes might help and it will make
> it easier to contribute back).
> 3) See which branch of batik.ext.awt.image.GraphicsUtils.drawImage
> you are taking, the tiled approach or the all at once approach
> (~line 300). Try forcing it to the all at once approach (may use
> lots more memory).
> 4) Try bypassing the Batik PNG Decoder (comment out the,
> registry.register(new PNGRegistryEntry());
> in batik.awt.awt.image.spi.ImageTagRegistry). I think there is
> a JDK decoder, which may be faster (but isn't conformant for
> SVG purposes as I recall - gamma). There are also significant
> oportunities for improvement in the PNG decoder.
> 5) Consider using the Batik multiImage extension (you can wrap it
> with a switch so you work with Adobe). To use this effectively
> you would need to manually tile your large image (say into 16
> parts). Then build a resolution hierarchy of those images.
> Batik can then fetch and render only those images needed for
> the current display (all 16 at low res down to 1 or 2 at higher
> resolutions). There is a simple example in samples/extensions
> directory. To use exentsions you need to includ the extensions
> classes in your class path which is most easily done by using
> the source distribution.
>
> I think 5 is the most likely to give fast/high quality results
> (you can use expensive techniques to generate very good low resoution
> images to reference from the multiImage tag), but means more work in
> creating the content and images (take a look at ImageMagik). Also
> there is serious consideration of adding something like the Batik
> multImage element to SVG in the future to meet exactly this sort of
> use case.
>
> I hope this helps, please take the time to report back.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Charles H. Woloszynski
ClearMetrix, Inc.
115 Research Drive
Bethlehem, PA 18015
tel: 610-419-2210 x400
fax: 240-371-3256
web: www.clearmetrix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
