United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4517321 : Java fails on 3-byte RGB screens used by some Linux implementations

Details
Type:
Bug
Submit Date:
2001-10-20
Status:
Resolved
Updated Date:
2002-11-12
Project Name:
JDK
Resolved Date:
2002-11-12
Component:
client-libs
OS:
solaris_7,linux_2.4
Sub-Component:
2d
CPU:
x86,sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Duplicate:

Sub Tasks

Description
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.


                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b07


                                     
2004-06-14
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
                                     
2002-11-01



Hardware and Software, Engineered to Work Together