Hi Justin, "Justin McCarthy" <[EMAIL PROTECTED]> wrote on 04/03/2006 03:27:07 PM:
> Unfortunately, encoding exactly the same SVG with exactly the same parameters, > 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 stuff which would enable you to use the javax.imageio PNG encoder which I think is native underneath. This might be much faster. Checking this is one of the 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 (I'm > logging the transcode after streaming the result to the browser). Here are > 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 JPEG? It is likely to be much slower. > The example image I provide below _is_ a photograph, and therefore transcodes > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
