FULL PRODUCT VERSION :
jdk6uN-b7

ADDITIONAL OS VERSION INFORMATION :
Windows-XP SP2

EXTRA RELEVANT SYSTEM CONFIGURATION :
 CheckAdaptersInfo
------------------
Adapter Ordinal : 0
Adapter Handle : 0x10001
  Description : ATI MOBILITY RADEON X700
GDI Name, Driver : \\.\DISPLAY1, ati2dvag.dll
Vendor Id : 0x1002
Device Id : 0x5653
SubSys Id : 0x2911462
Driver Version : 6.14.10.6505
GUID : {D7B71EE2-1513-11CF-BB6E-9B22A1C2CB35}
D3DPPLM::CheckDeviceCaps: adapter 0: Passed
------------------
D3DGD_getDeviceCapsNative
D3DContext::InitContext device 0
D3DContext::ConfigureContext device 0
[V] dwBehaviorFlags=D3DCREATE_FPU_PRESERVE|D3DCREATE_HARDWARE_VERTEXPROCESSING
D3DContext::ConfigureContext: successfully created device: 0
D3DContext::InitDevice: device 0
D3DContext::InitDefice: successfully initialized device 0
[V] | CAPS_DEVICE_OK
[V] | CAPS_ALPHA_RT_PLAIN
[V] | CAPS_ALPHA_RTT
[V] | CAPS_OPAQUE_RTT
[V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V] | CAPS_MULTITEXTURE
[V] | CAPS_TEXNONSQUARE


A DESCRIPTION OF THE PROBLEM :
We have created several applets which use LwVCL in order to provide a rich user-interface while staying Java-1.1 compatible. LwVCL uses XOR rendering in several places to show selected areas or lightweight window-borders while moving windows.

On the Laptop mentioned above the by default enabled D3D pipeline causes real usability problems, because even the 100x30px large selected XOR areas in trees introduceses a ~250ms latency, whereas moving the windows arround is almost impossible.

I don't know wether its system or hardware specific - I don't have access to windows systems for testing in general. If you're in doubt just fire up the applet mentioned below.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.) http://palme.agosys.com:9080/palme2007/PalmeStart
2.) Acceppt the certificate
3.) Expand the tree a bitSelect icons in the tree on the left - PalmeRoot->Divisions->Test-Abteilung
4.) Double-Click on "Test-Abteilung" -> a new window will open. Try to move it arround.
5.) Click on the mechanical-symbol top-right (in the applet-"desktop") to open the language-choose menu, move the mouse a bit over it.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
slowdowns, but at least acceptable speed, not making the application unuseable
ACTUAL -
While list-selection is just not beautiful, the window-moving-performance is really horrible.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Render to a BufferedImage, insetad of a VolatileImage as backbuffer
Same report from the CAP member:

J2SE Version (please include all output from java -version flag):
  java version "1.6.0_10"
  Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
  Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
   Not in jdk 1 6.0_06 and 6u7

Operating System Configuration Information (be specific):
  Windows XP PRO SP2
  IE 7.0

Hardware Configuration Information (be specific):
  HP Pavillion dv9000
  Windows Vista Business SP1 32 bit
  3 GB RAM
  Intel Core 2 Duo T9300



Bug Description:

XOR painting is unusably slow.  Any feature that uses it is inoperable.  This is likely related to 6737425 and 6635462.  Unfortunately, I did not test this particular feature before update 10 was released.  I am surprised to see that it had already been identified and is only a medium priority bug.  Unless a better workaround can be suggested, I would request that this be bumped in priority.

We are not using any 3D.  We are using it to draw a rectangular selection over a text area.    I am not sure any other way to do this (creating highlights will not work for what we want to do).  It sounds like my problem is similar to the problem mentioned (as a comment) in 6635462 about JDesktopPanel.OUTLINE_DRAG_MODE


Steps to Reproduce (be specific):

Run this app under jdk 1.6.0_06.  Perfect.

Starting fill
Finished, elapsed time = 0.0 seconds


Run this under 1.6.0_10

Starting fill
Finished, elapsed time = 23.904 seconds