If you construct an image from a MemoryImageSource that specifies an Alpha
mask then the image will render very slowly whether or not any of the pixels
was actually transparent or translucent.
Comments
WORK AROUND
Avoid specifying an Alpha mask in a DirectColorModel when the pixels are
known to be opaque.
11-06-2004
SUGGESTED FIX
Classify the resulting image based upon the pixels in the final result rather
than the ColorModel used to deliver the pixels.
11-06-2004
EVALUATION
We can scan the pixels in the resulting image when the imageComplete
notification is delivered and reclassify the image as XRGB if it was
formerly ARGB.
jim.graham@Eng 1999-09-28
Note that using an ARGB BufferedImage to store an opaque image will also
impact performance, but due to the potentially dynamic nature of an ARGB
image we would have to rescan the alpha components for each image operation
to see if it can be reclassified. Since BufferedImage objects have always
behaved this way, that behavior is not a regression from prior performance
and so we will only be looking to fix this bug for static images that are
produced using the ImageProducer/ImageConsumer paradigm.
jim.graham@Eng 1999-09-29
We have modified the Toolkit ImageConsumers to reclassify the image as an
opaque RGB image when the STATICIMAGEDONE notification is sent so that static
images will render at full speed. That solution won't help an animating
image that is the result of a MemoryImageSource with the setAnimated(true)
flag set, though. We are working on a way to dynamically reclassify the
image for each frame with less overhead...
jim.graham@Eng 1999-10-07