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

[Dmitri Trembovetski]

   Hi Jim,

   Yes, you're right: in both my tests I displayed to my
   sparc workstation display. When I displayed to my cygwin
   X server (which is Xrgb) on windows it did show the bug.

   Thanks,
     Dmitri


Jim Graham wrote:
> 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