Bug ID: JDK-4517321 Java fails on 3-byte RGB screens used by some Linux implementations

Versions (Unresolved/Resolved/Fixed)

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 Availability Release.

To download the current JDK release, click here.

Other
1.4.2 mantisFixed

Platfrom    Linux kali.sfbay.sun.com 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
Java        Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b83)


Running java2Demo on my GNU/Linux box I've got the following exception:

java.lang.InternalError: not implemented yet
        at sun.awt.X11SurfaceData.getRaster(X11SurfaceData.java:157)
        at sun.java2d.loops.OpaqueCopyAnyToArgb.Blit(CustomComponent.java:70)
        at sun.java2d.loops.GraphicsPrimitive.convertFrom(GraphicsPrimitive.java:455)
        at sun.java2d.loops.MaskBlit$General.MaskBlit(MaskBlit.java:188)
        at sun.java2d.pipe.AlphaPaintPipe.renderPathTile(AlphaPaintPipe.java:142)
        at sun.java2d.pipe.DuctusShapeRenderer.renderPath(DuctusShapeRenderer.java:109)
        at sun.java2d.pipe.DuctusShapeRenderer.fill(DuctusShapeRenderer.java:52)
        at sun.java2d.pipe.PixelToShapeConverter.fillRect(PixelToShapeConverter.java:47)
        at sun.java2d.SunGraphics2D.fillRect(SunGraphics2D.java:2104)
        at sun.java2d.SunGraphics2D.clearRect(SunGraphics2D.java:2144)
        at java2d.Intro$Surface.paint(Intro.java:278)
        at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4737)
        at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4690)
        at javax.swing.JComponent._paintImmediately(JComponent.java:4634)
        at javax.swing.JComponent.paintImmediately(JComponent.java:4466)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:407)
        at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:120)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:181)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:446)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:193)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:147)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:141)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:133)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:101)


There are XF86Config, output from xdpyinfo, output from java -Dsun.java2d.trace=log -jar Java2Demo.jar in 
the attachments.

I did not have this problem when I had  16 bits per pixel.
It happened after I chenged depth to 24

jdk1.3.1_01 does not have that problem.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b07

14-06-2004

EVALUATION According to xdpyinfo user has 24 bits per RGB pixel. Unfortunately the ThreeByteRgb loops are not yet implemented. ###@###.### 2001-10-22 There are some video boards like the submitter's Matrox Millenium II and the ATI Radeon 9700 that report having 24 bits per pixel, with a 3 byte pixel stride, with the ordering R, G, B. It turns out that we check the component masks returned by X11 for the visual and if the red mask is 0xff0000, we mark the surface as ThreeByteRgb. However, as far as our software loops are concerned (and X11 as well), these surfaces are better described as ThreeByteBgr. We already have ThreeByteBgr loops in place, so the fix here is fairly simple: just mark these surfaces as ThreeByteBgrX11 rather than ThreeByteRgbX11. Most everything works after making this change, except for the case when remote displaying from solaris-sparc to linux-i586. Because the endianness of the systems are different, we attempt to swap the bytes when using XGetImage() and XPutImage(). However, for some reason, this swap is unnecessary in this configuration, so the fix here is to avoid the swap if the configuration is 24 bpp, 3 byte pixel stride, and the red mask is 0xff0000. ###@###.### 2002-11-01

01-11-2002