xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: PNG transcoding time -- f(resulting file size)?
Date Mon, 03 Apr 2006 19:57:59 GMT
Hi Justin,

"Justin McCarthy" <justinamccarthy@gmail.com> wrote on 04/03/2006 03:27:07 

> Unfortunately, encoding exactly the same SVG with exactly the same 
> but substituting the PNGTranscoder for the JPEGTranscoder runs about 10x 

> slower. 

   Yah, the biggest problem is that the PNG encoder is 100% pure java and
the JPEG encoder is 100% native code.  You might try the new ImageWriter 
which would enable you to use the javax.imageio PNG encoder which I think 
native underneath.  This might be much faster.  Checking this is one of 
things on my TODO list.

> Here's the interesting part: at least 20% of the execution time in 
> the PNG scenario can be attributed to Firefox rendering the PNG slowly 
> logging the transcode after streaming the result to the browser).  Here 
> the logs; width=500, height=500; the final number is time, in ms: 

> Do we expect PNG transcoding to be an order of magnitude slower than 

   It is likely to be much slower.

> The example image I provide below _is_ a photograph, and therefore 
> much larger as PNG than JPEG.

   Essentially everything will transcoder much larger as PNG than JPEG
PNG is lossless and JPEG is lossy.

> Do we expect transcoding time to be linear with resultant file size? 
> Is IO the dominant component of any transcoding operation? 

   I don't think so, PNG may well be slower than JPEG but if both are
native I would expect them to be much closer.

> If so, I think the mystery is solved (and we'll just have to 
> figure a way to avoid PNG'ing certain graphics). 

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

View raw message