The gray box around your volatile image suggests trouble in this line:
I used the T6 in the tumbling duke image sequence from the sun example index. It has a white background and was being rendered on a white background in the app so I could have had some invisible artifacts. You could try the no–argument
repaint to see if it works any better. I may have messed up the clipping rectangle. Please let me know how you do with it.
Did you read Chet's
second article? It has some more code and information. I found that re–initializing the volatile image when
validate returns
VolatileImage.IMAGE_RESTORED (as shown in the articles and api) causes some tail–chasing: the renewed image triggers the IMAGE_RESTORED state.
I was pleased to find that the volatile image never needed to be re–initialized, even when I did some of the things on Chet's list of lost–data causes like launching the windows task manager. And I also could not distinguish any difference in appearance or performance between the volatile and buffered images.
I also observed the uneven motion of the image at high speeds near 10. I think this is caused by Swing adding separate calls to
repaint together as they pile up in the event dispatch
thread queue.