JDK-4673490 : REGRESSION: Some PNG images are not correctly displayed in Linux
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: client-libs
  • Sub-Component: 2d
  • Priority: P3
  • Affected Version: 1.4.0
  • OS: linux
  • CPU: x86
  • Submit Date: 2002-04-24
  • Updated Date: 2002-10-16
  • Resolved Date: 2002-10-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other
1.4.2 mantisResolved
Description

Name: jk109818			Date: 04/23/2002


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) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b04
2004-06-14

WORK AROUND Use -Dsun.java2d.pmoffscreen=false to disable the use of pixmaps. ###@###.### 2002-09-25
2002-09-25

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. ###@###.### 2002-09-25
2002-09-25