How to improve load time of PNG images?

[Mark Vidov <mv...@hotmail.com>]

What can be done to improve load times of PNG images? Can batik be made to 
use JAI and its native libraries? Is there a portion of batik that that can 
be optimized or skipped to improve this specific case (eg decoding, scaling, 
rendering)?

Some details:

I'm using batik to display very simple svgs consisting of an image tag and a 
handful of simple elements (text, rect). The images are PNG files, with a 
typical file being 3200 x 2200 x 4 color (file size around 240KB).

Load times in squiggle (PIII 1000MHz, GeForce2) are 6-8 seconds (GVT build 
around 3500ms and GVT render around 3500ms). Total load time in Adobe SVG is 
less than 1 second.

Loading and rendering the PNG file in java using Graphics.drawImage with 
scaling (Image.SCALE_FAST) is around 10 seconds.

However when I use JDK 1.4.0 with JAI 1.1.1 java rendering drops to less 
than 2 seconds. Using the same JDK and JAI with squiggle produces no 
improvement.

I'm wondering why JAI adds no benefit. The comparison to Adobe is also 
shocking. (Adobe also uses some smoothing to make my PNG files look much 
better than in batik.)

This issue is critical and my only alternative seems to be to wrap Adobe 
with JNI (a big pain since Adobe no longer supports its COM interfaces).

Any ideas or comments would be much appreciated.

_________________________________________________________________
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

How to improve load time of PNG images?

[Thomas E Deweese <th...@kodak.com>]

>>>>> "MV" == Mark Vidov <mv...@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