In 6 and earlier if you call Raster.getDataBuffer() or if you
constructed your own Raster from a DataBuffer then you would defeat
acceleration permanently.
In 7 we have a newer tracking system that lets you access the DataBuffer
object and use its get/set methods without defeating acceleration, but
if you construct a DB from your own array or if you use one of the
getData() methods that returns you the Java array then the acceleration
will still be defeated. We have no magic tracking mechanisms that can
avoid this, but the DataBuffer.get/set methods are fairly quick so at
least you can get one step closer to the bits in this new scheme...
...jim
Harald Kuhr wrote:
On 27. aug.. 2008, at 12.05, [EMAIL PROTECTED] wrote:
Calling the BufferedImage constructor directly or using one obtained
through ImageIO or GraphicsConfiguration will return a managed image.
[...]
Further, if you try and grab the image data directly by calling
getDataBuffer() on the Raster, then it will be permanently
unaccelerated so if you want to make changes to the image, then stick
with Graphics calls.
Just curious. I guess this is not the case, but... If I create a new
BufferedImage from a Raster, and the Raster is again created from a
DataBuffer created with a preallocated data array, will it still be
managed/accelerated? I can easily hold on to and mutate the data array,
and the docs clearly says the array is not cloned (for performance). Or
is there some magic code that knows that I don't hold on to the
reference any more?
In my ImageIO plugins I often access the data buffer directly, and write
to the data array, because it's the fastest way to read typical pixel
data. I guess I should stop doing that...
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
