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

Reply via email to