Copying an image into Swing's default back buffer using alpha compositing 
is way slower than it was in jdk1.3.1.  The same is true for copies into 
any VolatileImage (such as Swing uses for its back buffer).

Run the attached AutoTest app.  Click on the overlay (translucent) image and
drag it around the screen.  On jdk1.3.1, you should see farily snappy
performanc.  On jdk1.4, however, you will notice very choppy behavior as each
frame of the animated dragging takes a long time to render.

-----------------------

This is also a problem with the new XP look and feel work in Swing.  Due to the
many translucent components in this look&feel, we end up punting the Swing
back buffer and then get poor performance for other opaque images
that still exist in VRAM.

  xxxxx@xxxxx   2003-01-23

N/A

At first this looked like a problem with our VolatileImage punting mechanism.
We have a mechanism inside of VolatileImage that detects when lots of reads
are happening on that image (reads are a Bad Thing when an image is cached
in VRAM) and punts that image into system memory when the number of pixels
read surpasses some threshold.  If the mechanism was not working correctly,
we could be stuck with a back buffer in VRAM that is being used for lots
of read operations, causing hte kind of bad performance that we are seeing.

But, in fact, our image punting mechanism is working fine; we detect the
read-modify-write situation at work in this app and correctly punt the
image to live forever in system memory.

The problem is that the two non-VolatileImage objects in this app end up
living in VRAM.  And since we copy from those two images on every frame,
our performance problem is due to reading from those VRAM images and not
anything to do with the Swing back buffer itself.

The bug is in how we punt the image and how we determine when we can
accelerate operations such as copies between images.  Currently, the 
VolatileImage object lives as a DirectDraw surface on Windows.  When we
punt the image into system memory, we do this within DirectDraw; it is still
represented as a DDraw surface, but just happens not to live in VRAM.
The bg and fg images are loaded by ImageIcon and thus live in system
memory (as BufferedImage objects).  But we detect the case where we copy from
a software image to a DirectDraw image and attempt to accelerate this 
situation by creating a DDraw/VRAM-cached version of the image under the hood.
Subsequently, copies from this type of image to any DirectDraw surface
(including the screen) will come from the cached version of the image
instead of the original system memory version.

The problem here is that we do not distinguish between ddraw VRAM images
and ddraw system memory images.  So when we decide to copy from the
bg image to the Swing back buffer, we detect that the back buffer is a ddraw
surface and thus use the cached bg image and call DirectDraw::Blt() to do
the copy.  But since the back buffer now lives in system memory, this Blt
call will need to read from VRAM for the bg image (instead of the expected
hardware-accelerated VRAM->VRAM copy if the back buffer were actually in VRAM).

The fix could take several forms.  But the most straightforward fix would
probably including being able to distinguish between ddraw system and ddraw
VRAM surfaces and taking that information into account when deciding which
routines to use and image versions to use during copying operations.

  xxxxx@xxxxx   2002-01-31

Fixed as suggested above; we now set a flag at the Java level to indicate when
an image has been punted into ddraw system memory.  Then later operations to
that image (such as copying an image to that buffer, as in the AutoTest app
attached to this bug) will detect that punt and use the system memory version
of the source image instead, thus preventing the read-from-VRAM problem
that caused this bug.

  xxxxx@xxxxx   2003-01-23