xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Vidov" <mvi...@hotmail.com>
Subject Re: How to improve load time of PNG images?
Date Mon, 19 Aug 2002 13:19:48 GMT
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 <thomas.deweese@kodak.com>
Reply-To: "Batik Users" <batik-users@xml.apache.org>
To: Batik Users <batik-users@xml.apache.org>
Subject: How to improve load time of PNG images?
Date: Tue, 13 Aug 2002 08:19:06 -0400

 >>>>> "MV" == Mark Vidov <mvidov@hotmail.com> 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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message