The per-pixel overhead of accessing VRAM would probably be more
noticeable than the per-operation overhead of getting the pixels into
the pipeline - unless there was a lot of overlap between the sysmem images.
With little or no overlap then it might even be faster to blit the
component sysmem
The per-pixel overhead of accessing VRAM would
probably be more
noticeable than the per-operation overhead of getting
the pixels into
the pipeline - unless there was a lot of overlap
between the sysmem images.
With little or no overlap then it might even be
faster to blit the
If VRAM is expensive to store per-pixel then the cost you pay to do the
blit(s) is dependent on the number of pixels.
If you are writing to the same VRAM pixels over and over because the
sysmem images overlap then you pay the cost to access pixels that will
later be overwritten.
By contrast
Hi,
I have a situation where I want to do a hybrid of vram image blits sysmem
image blits. The software image blits are just pixel arrays that get drawn into
a big array representing the screen (framebuffer). I use this for images I'd
like to do certain operations on only doable in software.
Hi,
I don't quite understand the question. Why couldn't you just
render all your images (the sysmem ones, which I assume are
BufferedImages) and the vram-based ones (VolatileImages or
cached BufferedImages?) to your back-buffer (which resides in
vram)?
Whatever order you draw them
