SUGGESTED FIX

http://hg.openjdk.java.net/jdk7/2d/jdk/rev/8eb24fc88242
                                     

EVALUATION

A better fix is to use proper convert loop from IntRgb to Argb instead of
generic Iso one, so that destination alpha is set to FF during the
conversion.
                                     

EVALUATION

The problem is that the source image, while opaque, has non-ff alpha in some of the pixels.

The pipeline uses ARGB tile texture for rendering from sw image, and since in this case alpha compositing is enabled, we end up getting unexpected results from compositing.

The fix is to use an opaque tile texture for opaque sources. While we should only 
really need opaque source when AC is enabled, it's probably no harm in using it any 
time there's an opaque source. It's possible that there will be more texture 
switching because of this.
                                     

EVALUATION

There may be something else to this as well, as this fix addresses some artifacts in the demos
which it doesn't look like it should..
                                     

EVALUATION

If the test is modified, so all the buffered images are cached (see diffs below), the problem goes away:

***************
*** 21,26 ****
--- 21,27 ----
        private int tr;
        private float a;
+       BufferedImage bim;
        public AlphaComponent(int transparency, float alpha)
        {
***************
*** 39,50 ****
          gg.setColor(Color.RED);
          gg.fillRect(GAP, GAP, w * 3 / 4, h * 3 / 4);
!         GraphicsConfiguration gc = getGraphicsConfiguration();
!         BufferedImage bim = gc.createCompatibleImage(w * 3 / 4, h * 3 / 4, tr);
!         Graphics2D g2 = bim.createGraphics();
!         g2.setColor(new Color(0, 0, 255, 150));
!         g2.fillRect(0, 0, w * 3 / 4, h * 3 / 4);
!         g2.dispose();
          gg.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, a));
          gg.drawImage(bim, GAP + w / 4, GAP + h / 4, null);
--- 40,54 ----
          gg.setColor(Color.RED);
          gg.fillRect(GAP, GAP, w * 3 / 4, h * 3 / 4);
!         int bw = w * 3 / 4, bh = h * 3 / 4;
!         if (bim == null || bim.getWidth() != w || bim.getHeight() != bh) {
!             GraphicsConfiguration gc = getGraphicsConfiguration();
!             bim = gc.createCompatibleImage(bw,bh, tr);
!             Graphics2D g2 = bim.createGraphics();
!             g2.setColor(new Color(0, 0, 255, 150));
!             g2.fillRect(0, 0, bw, bh);
!             g2.dispose();
!         }
          gg.setComposite(AlphaComposite.getInstance(AlphaComposite.SRC_OVER, a));
          gg.drawImage(bim, GAP + w / 4, GAP + h / 4, null);
                                     

EVALUATION

Yes, it looks like a bug in our bi to accel surface
blit loop.

If the test is modified to cache the image instead of
creating it on every repaint (see diff below), it works
correctly, which means that once we cache the image in
a texture, the extra alpha is applied correctly.