How to render TRANSLUCENT VolatileImages reliably?

Java 2D
#1

I brought this issue up months ago, back in 1.4.0 as a potencial problem when TRANSLUCENT VolatileImages eventually get implemented.

Now in 1.5 they finally have been I’m not seeing anything in the API that has been changed to ever make TRANSLUCENT VolatileImages work reliably.

The loop suggested in the API for ensuring a VolatileImage is draw correctly simply does not work when dealing with TRANSLUCENT images, the reason is because when performing a TRANSLUCENT blit, both the source and destination pixels contribute to the resultant pixel color.
The destination pixel will therefor be effectively corrupt if you render the source image twice.

Heres the sequence of operations that causes the problem.

  1. Validate VolatileImage to make sure its ok to blit.

  2. blit it to the backbuffer.

3) outside event causes the VolatileImage to lose its contents.

  1. contentsLost is called, and returns true.

  2. so your code has to restore the VolatileImage.

  3. and then re-blit it to the backbuffer. etc etc.

This loop could potencially go on forever, but for simplicity lets say it happens only twice.
This still means a TRANSLUCENT image has been rendered onto the backBuffer twice, when it should have only been rendered once.
This will result in incorrect pixel values in the destination.

So, am I missing something - or are Volatile TRANSLUCENT images kinda fundamentally buggy?

[edit]
I guess the simplest solution is to change the definition what contentsLost() returns.

Instead of a boolean indicating whether the contents has been lost since the last call to validate(),
it should be changed to indicate if the contents has been lost since the last time the image was drawn?
[/edit]

p.s. I assume managed BufferedImages can behave in the exact same way, as their cached copy in vram can potencially lose its contents at any time also?

#2

p.s. I assume managed BufferedImages can behave in the
exact same way, as their cached copy in vram can
potencially lose its contents at any time also?

AFAICR their copy is stored in RAM not VRAM (storing the copy in vram doen’t make much sense does it?)

#3

[quote]> p.s. I assume managed BufferedImages can behave in the

exact same way, as their cached copy in vram can
potencially lose its contents at any time also?

AFAICR their copy is stored in RAM not VRAM (storing the copy in vram doen’t make much sense does it?)
[/quote]
I’m going to assume you misread, or misunderstood what I said ???

managed BufferedImages are cached in VRAM, so they can be HW accelerated.

#4

Excuse my sillyness ;D

Well, one “copy” is stored in ram and the other one in vram. And yea, it can of course loose it’s content, too… in that case the ram copy jumps in.

For that reason I just use managed BufferedImages. I don’t really see an advantage in using volatile images, because I would have to care about that stuff myself.