Write to bufferedimage and compatibleimages

Question

hey
you maybe remember that I made a breakout game, i use compatibleimages in fullscreen and draw them alot of times..300+
someone told me to use a bufferedImage and draw the image to this bufferedImage first then just blit the bufferedImage.
is this correct?will that result in 1 blit instead of 300? and is if faster? the game has 70 fps now.

Answer 1

hmm, the answer can be either yes or no.
edit ESSAY ALERT :D
if hardware acceleration is supported, your current way of doing it will be quicker.
If hardware acceleration is not supported, reducing the number of blits may well increase speed.
heres an outline of what the processes involve :-
When hardware acceleration is supported
A) Blitting each block seperately
1) the framebuffer (back & front buffers) are both stored in vram.
2) each blocks image is stored in main memory, and cached in vram.
3) any blit operations are vram->vram, hence have near zero execution cost.
B) Blitting each block to an intermediary image (when a change occurs), then blitting this intermediary image to the frame buffer.
1) the frame buffer (back & front buffers) are both stored in vram.
2) each blocks image is stored in main memory, and cached in vram. (though the vram cached version will never be used)
3) the intermediary image is stored in main memory, and cached in vram.
4) the regular blit operation will be
intermediary image->frame buffer
since both of these are in vram, the cost is near zero.
5) when the intermediary image changes, the blit operation is
blocks image->intermediary image
since both these images have their original image stored in main memory,
this blit is a main mem.->main mem. hence, will incur a speed cost.
6) ALSO, when the intermediary image changes, the version cached in vram
becomes invalid, and the image needs to be re-cached.
This is a main mem.->vram copy, which also incurs a cost.
If the intermediary image changes often, this will result in a drop in framerate each time a change occurs.
(inconsistant framerates are VERY bad from a human perception POV)
C) use a VolatileImage object for the intermediary image
This is the best solution, as it removes all main mem->vram blits, and also reduces the vram->vram blits to an absolute minimum.
However,
the real speed difference between 300 vram blits
and 1vram blit(+1 vram blit each time a change occurs)
is absolutely minimal.
(infact, because this isnt your bottleneck the speed difference will be zero)
When hardware acceleration is NOT supported
A) Blitting each block seperately
1) the back buffer is in main mem. the front buffer is in vram.
2) each blocks image is stored in main memory.
3) each block blit is main mem.->main mem. (costly)
PLUS the back buffer has to be blitted onto the front buffer, this is a main mem.->vram blit.
B) Blitting each block to an intermediary image (when a change occurs), then blitting this intermediary image to the frame buffer.
1) the back buffer is in main mem. the front buffer is in vram.
2) each blocks image is stored in main memory.
3) the intermediary image is stored in main mem.
4) the regular blit operation will be
intermediary image->back buffer
this is a single main mem.->main mem. blit.
5) also, each time the intermediary image changes,
you will get an extra main mem->main mem blit.
6) you also have the obligatory back buffer->front buffer blit
Comparing the 2 methods when there is no hardware acceleration available
you will see that the 2nd technique does indeed require fewer blits.
(instead of 300 every frame, your doing 1+[1 each time a change occurs])
So, now your left with the question, 'which do I use?'
well, its totally down to whether you expect hardware acceleration to be available or not :S
The ideal solution is to write 2 versions,
not very 'Java', but its the way the world is :[