[OpenJDK 2D-Dev] 6603887: Where are transparent areas filled with bgColor?

[Jim Graham]

Perhaps the difference is that Dmitri is running on a display with Xbgr 
which has to decompose the argb value and recompose it into a BGR value 
- in the process it only moves the r, g, and b bits around.

Clemens is running on an Xrgb screen and so the pixelconverter just 
passes on the argb value as the pixel - alpha bits and all - as he 
discovered.  That's safe for most purposes since the alpha value should 
be ignored, but causes a problem with this "+1" hack.  I think we ran 
into a case internally where the extra bits of the pixel value did cause 
a problem with some of the Solaris X11 drivers, but we proposed that it 
was a violation of X protocol and the driver was fixed.

The simplest fix would probably be to just mask off the alpha in 
rgbToPixel and stop "playing with fire" by leaving the alpha bits set. 
This could also be done more specifically in the BlitBg support code 
(mask the pixel and +1 to see if it is set yet or not).  The most robust 
fix is to add a boolean as originally proposed...

			...jim

Clemens Eisserer wrote:
> Hi Dimitri,
> 
>>    I'm having issues with reproducing the bug with
>>    this or the original test.
>>    I've tried on solaris and linux, it works fine in
>>    both cases on all jdks I've tried. Weird.
>>    What is your desktop bit depth?  I've tried on 24bit
>>    systems.
> My display also has 24bit depth, when I switch to 16bit, pixel has
> some ~65535 value and everything works as expected.
> I am using Fedora7, updated once or twice, my Laptop has an Intel
> GMA950, using the i810 driver.
> 
>>    In the debugger I see that the pixel passed to
>>    X11SD_GetPixmapWithBg is 0x00ffffff, not 0xffffffff,
>>    so pixel+1 != 0 .
> Wow thats really weird, however from the pixel-point-of-view it makes
> sence - 24 bytes are 1.
> 
> I did some debugging, and that's the stack where I get the pixel-value from:
>   PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143
>   SurfaceType.pixelFor(int, ColorModel) line: 434
>   X11SurfaceData$X11PixmapSurfaceData(SurfaceData).pixelFor(int) line: 835
>   X11PMBlitBgLoops.BlitBg(SurfaceData, SurfaceData, Composite, Region,
> Color, int, int, int, int, int, int) line: 90
>   BlitBg$TraceBlitBg.BlitBg(SurfaceData, SurfaceData, Composite,
> Region, Color, int, int, int, int, int, int) line: 211
>   DrawImage.blitSurfaceData(SunGraphics2D, Region, SurfaceData,
> SurfaceData, SurfaceType, SurfaceType, int, int, int, int, int, int,
> Color) line: 957
>   DrawImage.renderImageCopy(SunGraphics2D, Image, Color, int, int,
> int, int, int, int) line: 575
>   DrawImage.copyImage(SunGraphics2D, Image, int, int, Color) line: 71
>   DrawImage.copyImage(SunGraphics2D, Image, int, int, Color,
> ImageObserver) line: 1008
>   SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: 3053
>   ImageRepresentation.drawToBufImage(Graphics, ToolkitImage, int, int,
> Color, ImageObserver) line: 764
>   DrawImage.copyImage(SunGraphics2D, Image, int, int, Color,
> ImageObserver) line: 1015
>   SunGraphics2D.drawImage(Image, int, int, Color, ImageObserver) line: 3053
>   BgRegTest.start() line: 39
>   AppletViewerPanel(AppletPanel).run() line: 476
>   Thread.run() line: 659
> 
> Its  simply returns the parameter we hand in from Color.getRGB(), my
> SurfaceData-Object is a
> sun.java2d.x11.X11SurfaceData$X11PixmapSurfaceData.
> Could it be a bug or no clear specification in
> PixelConverter$Xrgb.rgbToPixel(int, ColorModel) line: 143 be:
> 
> 	public int rgbToPixel(int rgb, ColorModel cm) {
> 	    return rgb;
> 	}
> 
> 	public int pixelToRgb(int pixel, ColorModel cm) {
> 	    return (0xff000000 | pixel);
> 	}
> 
> rgbToPixel simply returns the rgb value, but  pixelToRgb sets the
> first two bytes. The question is why doesn't it look like:
> public int rgbToPixel(int rgb, ColorModel cm) {
> 	    return rgb & 0x00ffffff;
> 	}
> 
> I am using jdk7b19, so maybe some things have changed already :-/
> 
> ------------
> 
> I wonder how the code does/should behave in the 32-bit depth case?
> Wouldn't be a -1 value be possible in this case?
> 
> lg Clemens