Graphics.drawImage(Image, int, int, Observer) fails on custom CompositeMode

Question

We created some custom CompositeModes for which the following trivial example code is representative:
import java.awt.*;
import java.awt.image.*;
public class AddARGBComposite implements Composite
     static private AddARGBComposite instance = new AddARGBComposite();
     final private float alpha;
     public static AddARGBComposite getInstance( final float alpha )
          if ( alpha == 1.0f ) { return instance; }
          return new AddARGBComposite( alpha );
     private AddARGBComposite()
          this.alpha = 1.0f;
     private AddARGBComposite( final float alpha )
          this.alpha = alpha;
     public CompositeContext createContext( ColorModel srcColorModel, ColorModel dstColorModel, RenderingHints hints )
          return new CompositeContext()
               public void compose( Raster src, Raster dstIn, WritableRaster dstOut )
                    final int[] srcPixel = new int[ 4 ];
                    final int[] dstInPixel = new int[ 4 ];
                    for ( int x = 0; x < dstOut.getWidth(); x++ )
                         for ( int y = 0; y < dstOut.getHeight(); y++ )
                              src.getPixel( x, y, srcPixel );
                              dstIn.getPixel( x, y, dstInPixel );
                              final float srcAlpha = srcPixel[ 3 ] / 255.0f * alpha;
                              dstInPixel[ 0 ] = Math.min( 255, Math.round( srcPixel[ 0 ] * srcAlpha + dstInPixel[ 0 ] ) );
                              dstInPixel[ 1 ] = Math.min( 255, Math.round( srcPixel[ 1 ] * srcAlpha + dstInPixel[ 1 ] ) );
                              dstInPixel[ 2 ] = Math.min( 255, Math.round( srcPixel[ 2 ] * srcAlpha + dstInPixel[ 2 ] ) );
                              dstInPixel[ 3 ] = 255;
                              dstOut.setPixel( x, y, dstInPixel );
               public void dispose()
}Using this CompositeMode for composing two images using the trivial method fails :
BufferedImage image1, image2;
Graphics2D g = image1.getGraphics();
g.setComposite( AddARGBComposite.getInstance( 0.5f )  );
g.drawImage( image2, 0, 0, null );Using a trivial AfifneTransform, it also fails because for integer translation, Graphics seems to fall back to the integer method above:
AffineTransform at = new AffineTransform();
g.drawImage( image2, at, null );But for non-trivial AffineTransforms, it works perfectly:
at.scale( 0.5f, 0.5f );
g.drawImage( image2, at, null );We reproduced this on the Linux64 and Windows64 platform both with an Nvidia-graphics device and latest Sun Java 6 update 16.
Is the bug on our side missing something in the CompositeMode implementation or is this a bug in java.awt?
Thanks in advance for any helpful comments.

Answer 1

First, can you explain what you mean by fail - Is your compose method never called? Does it get called, but the results are unexpected? What are the results? Or is just as if image2 was never drawn?
Second, In you're test case, what types are image1 and image2?
BufferedImage image1, image2; //<-----
Graphics2D g = image1.getGraphics();
g.setComposite( AddARGBComposite.getInstance( 0.5f )  );
g.drawImage( image2, 0, 0, null );You're making two assumptions in your AddARGBComposite code: 1) The source image has an alpha channel and is un-premultiplied, and 2) both the source and destination images are in rgb space. This could conceivably cause certain combinations of image types to fail, which is why I ask what types your image1 and image2 are. All other things considered, it seems to work on my machine. Though I'm in a Windows32 environment with 1.6.0_16.
From experience though, there is a problem with creating a custom composite and using GUI widgets under the new D3D graphics pipeline that was made the default since java 1.6.10 (I think that's when it was made default, I can't remember).
Basically, one or all of src, dstIn, and dstOut use a DataBuffer of type D3DNativeDataBuffer. And traditional calls into this native DataBuffer to retrieve or set data elements end up creating a non-trivial object or two. Multiply that object creation by the many thousands of pixels in a single image and you have a noticiable slow down. It's a similar reason why drawing a BufferedImage.TYPE_CUSTOM is pretty slow.
Again, this only applies to throwing GUI widgets into mix, not drawing one user-created BufferedImage ontop of another.