Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
From: bugzilla@apache.org
To: general@xmlgraphics.apache.org
Subject: [Bug 51149] [PATCH] slowdown in PNG processing when switching from
 JDK 1.6.0_17 to 1.6.0_18
Date: Tue, 04 Sep 2012 15:43:41 +0000
Message-ID: <bug-51149-45363-P81Re762X2@https.issues.apache.org/bugzilla/>
In-Reply-To: <bug-51149-45363@https.issues.apache.org/bugzilla/>
References: <bug-51149-45363@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Auto-Submitted: auto-generated
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=51149

--- Comment #13 from Luis Bernardo <lmpmbernardo@gmail.com> ---
not quite correct...
- xmlgraphics pre 1.4 ignored color profiles; it was fast but in some cases the
output would be wrong (but most of the time was correct because ignoring the
color profile had no visible effect);
- with jdk 1.6.0_17, a new performance problem appeared but this was due to a
change (a bug fix) inside the jdk that caused the xmlgraphics to take a
different, and slower, path with some images; with the examples I checked the
images had a color profile but I don't know whether that was relevant; a patch
was submitted that tried to alleviate the performance impact, but the code was
still slower than   with a jdk pre 1.6.0_17;
- the ImageLoaderRawPNG is faster in many situations (in particular with large
images that use the Paeth filter) and the resulting file is usually smaller but
not always, and that is particularly true after support for color profiles was
added; the color profile is now (if different from the default one sRGB
IEC61966-2.1) embedded in the output PDF which may result in larger file size;
but if the color profile is the default one then I expect the ImageLoaderRawPNG
to be faster and produce smaller file sizes in most cases when compared with
the default ImageLoaderImageIO (with the caveat that only images with 8 bits
per channel and without interlacing are supported);
- bug 40676 can be reopened but as the bug title says, the main issue of the
bug was file size, not performance.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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