|
Description
|
FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
FULL OPERATING SYSTEM VERSION :
Redhat Linux 7.2 Kernel 2.4.7-10 Glibc 2.2.4 XFree 4.1.0-15
A DESCRIPTION OF THE PROBLEM :
Some PNG images are not correctly displayed by JDK 1.4 on
Linux. The same images are correctly displayed by JDK 1.4 on
Windows, or on JDK 1.3 on Linux.
REGRESSION. Last worked in version 1.3.1
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
To reproduce the bug. Run the code below with the following
image :
http://www.mirguet.net/bug_jdk1.4/Select.png
The same code works with JDK 1.3.1
and works with JDK1.4.0 on Windows
EXPECTED VERSUS ACTUAL BEHAVIOR :
I expect to see my image in a button.
I see another image.
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class PngCrashTest {
public PngCrashTest() {
// frame
JFrame frame = new JFrame("PngCrashTest");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().setLayout(new FlowLayout());
// button with a png image
ImageIcon ic = new ImageIcon("Select.png");
JButton b = new JButton("png",ic);
frame.getContentPane().add(b);
// show the frame
frame.pack();
frame.show();
}
public static void main(String[] argv) {
PngCrashTest test = new PngCrashTest();
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
some png images still work fine.
Release Regression From : 1.3.1_03
The above release value was the last known release where this
bug was known to work. Since then there has been a regression.
(Review ID: 145658)
======================================================================
|
|
Evaluation
|
The provided sample PNG image has two colors, black and a transparent color,
so we tag this as a ByteBinary1Bit surface. If the use of pixmaps is enabled
(it is on by default on Linux, on if DGA is not used on Solaris, or on if
forced by the -Dsun.java2d.pmoffscreen=true flag), we use a hidden acceleration
mechanism to cache the system memory representation of the "pointer" image in
a pixmap, for better acceleration when copied to the screen repeatedly. The
problem is that this image has a transparent pixel, so the cached pixmap is
of type Int*X11_BM. This means we have to setup a transparency mask for that
pixmap after we've cached the data, thus marking the transparent areas. The
code that does this marking process (in X11OffScreenImage.c) assumes ByteIndexed
data if there is an IndexedColorModel. But in this case, the image has an ICM,
but has packed pixel data (1-bit per pixel). Since the native masking code
does not know how to handle this surface type, it ends up incrementing along
the raster too "quickly", and thus the resulting cached image looks skewed.
One solution would be to fix this native marking code to handle ByteBinary
data, but since this is such a corner case and to avoid complex code in this
masking method, it would be best to simply add a check in X11ImageRepresentation
so that it does not attempt to create a cached pixmap for ByteBinary*Bit images
that are BITMASK transparent.
xxxxx@xxxxx 2002-09-25
|
