Mechanism to associate BufferedImage with internal rendering data is slow

In 1.4 a mechanism was created to be able to store or cache
internal rendering information on a BufferedImage object. A
hidden field was added which can contain a reference to an
object used by the internal rendering code to store information
about the type of image, how to treat it, and information on
cached copies of the data in hardware accelerators.

Since the field was non-public, there was no direct way to access
this field from the rendering code which lived in another package
(BufferedImage is in java.awt.image and the rendering code is all
in sun.* packages). As a result, a native method was created to
retrieve the contents of this field. Since accesses via JNI are
not checked for access controls, the native method could reach
this field whereas Java code could not.

Unfortunately, the cost of this native method is fairly high
with current VMs and for the foreseeable future. A simple test
to avoid the call on image rendering shows that very tiny
image blits on Solaris/Sparc could go as much as 25% faster
if this call is avoided.

###@###.### 2005-03-26 00:11:16 GMT