Return-Path: Delivered-To: apmail-xmlgraphics-batik-users-archive@www.apache.org Received: (qmail 23570 invoked from network); 3 Apr 2006 19:58:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Apr 2006 19:58:25 -0000 Received: (qmail 12320 invoked by uid 500); 3 Apr 2006 19:58:24 -0000 Delivered-To: apmail-xmlgraphics-batik-users-archive@xmlgraphics.apache.org Received: (qmail 12304 invoked by uid 500); 3 Apr 2006 19:58:24 -0000 Mailing-List: contact batik-users-help@xmlgraphics.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: batik-users@xmlgraphics.apache.org Delivered-To: mailing list batik-users@xmlgraphics.apache.org Received: (qmail 12293 invoked by uid 99); 3 Apr 2006 19:58:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 12:58:24 -0700 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=NO_REAL_NAME,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of thomas.deweese@kodak.com designates 192.232.121.200 as permitted sender) Received: from [192.232.121.200] (HELO smtp1.kodak.com) (192.232.121.200) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 12:58:23 -0700 Received: from roc-us-e1000-111.kodak.com (roc-us-e1000-111.kodak.com [192.232.121.191]) by smtp1.kodak.com (8.11.3/8.11.1) with SMTP id k33Jw2t12362 for ; Mon, 3 Apr 2006 15:58:02 -0400 (EDT) Received: from (150.221.122.53) by roc-us-e1000-111.kodak.com via smtp id 0857_289613f6_c34c_11da_81bf_0002b3efa0be; Mon, 03 Apr 2006 15:58:01 -0400 In-Reply-To: To: batik-users@xmlgraphics.apache.org Cc: batik-users@xmlgraphics.apache.org Subject: Re: PNG transcoding time -- f(resulting file size)? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: thomas.deweese@kodak.com Date: Mon, 3 Apr 2006 15:57:59 -0400 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 6.5.4FP1|June 19, 2005) at 04/03/2006 03:58:02 PM, Serialize complete at 04/03/2006 03:58:02 PM Content-Type: text/plain; charset="US-ASCII" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi Justin, "Justin McCarthy" 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: batik-users-unsubscribe@xmlgraphics.apache.org For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org