This bug was originally filed as bug 4952906. Due to the nature and timeframe of the fix, that bug was "fixed" by a workaround in the Swing code for Beta1. however, the underlying problem in java2D is not fixed by that Swing workaround; customers can still run into this problem in their own applications. I will submit a regression test that demos the problem clearly, but the basic problem is as follows:

- Given a typical paint() method in which we copy VolatileImage objects onto a Swing back buffer (or other vram-based image Graphics):

public void paint(Graphics g) {
do {
int valCode = vImg.validate(gc);
if (valCode == VolatileImage.IMAGE_RESTORED) {
// restore contents
} else if (valCode == VolatileImage.IMAVE_INCOMPATIBLE){
// recreate/restore
}
g.drawImage(vImg, x, y, this);
// etc.
} while (vImg.contentsLost());
In this situation, the call to drawImage() may set the internal surfaceLost
flag on vImg even though vImg is not currently in a lost state. This is because we are not being specific enough when we get errors during the drawImage call, so if the destination image (the VolatileImage that owns the Graphics object) is lost, that problem will progate itself to any VolatileImage sources of any drawImage() calls like this one. Since we cannot restore (via validate()) the destination image in this loop, we will spin forever, revalidating the source image(s) and then having them get flagged as lost again when we try to render to the lost destination buffer.

All of the comments in 4952906 apply here as well...