Bug ID: JDK-4631352 Translucent image copies to Swing back buffer slow in jdk1.4 (Windows only)

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 1.4.0,1.4.2

Priority: P2
Status: Resolved
Resolution: Fixed
OS: windows_nt,windows_2000,windows_xp
CPU: x86

Submitted: 2002-01-31
Updated: 2013-11-01
Resolved: 2003-02-03

Other
1.4.2 b16Fixed

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.

###@###.### 2003-01-23

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta tiger FIXED IN: mantis-beta tiger INTEGRATED IN: mantis-b16 mantis-beta tiger tiger-b05

14-06-2004

EVALUATION 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. ###@###.### 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. ###@###.### 2003-01-23

23-01-2003