United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6635462 D3D: REGRESSION: XOR rendering is extremly slow
JDK-6635462 : D3D: REGRESSION: XOR rendering is extremly slow

Details
Type:
Bug
Submit Date:
2007-11-29
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
client-libs
OS:
windows_xp
Sub-Component:
2d
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6,6u10,6u12
Fixed Versions:

Related Reports
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
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

                                    

Comments
EVALUATION

Yes, unfortunately this is a known limitation of the current
implementation because there is no easy way to express
xor operation in D3D9.

One way we could work around this problem is to disable
acceleration for surfaces to which xor rendering is detected.
That at least wouldn't lead to huge performance issues,
even though application will not take advantage of 
the rest of hw accelerated rendering.
                                     
2007-11-29
WORK AROUND

A few workarounds:

1. disable the use of the Direct3D pipeline by providing -Dsun.java2d.d3d=false property. This may result in overall performance degradation, but if your application depends heavily on xor, this may be an option. There's a way to provide this property as applet argument if needed in the new plugin in 6u10: http://java.sun.com/javase/6/webnotes/6u10/plugin2/jnlp/#COMMAND_LINE_ARGS

2. Reconsider the use of XOR operation. Often Xor is used to minimuse repainting by re-rendering the same primitive twice instead of repainting.

This used to be a relevant optimization, especially when rendering directly to the screen, since rendering was relatively slow. 
It is questionable if this really all that necessary nowadays.
So instead of re-doing the operation with xor mode set, consider just repainting the affected area.

3. if you still think you have to use xor, consider doing the rendering that requires xor in a separate BufferedImage, and then copying it to the backbuffer.
                                     
2009-01-10
EVALUATION

http://hg.openjdk.java.net/jdk7/build/jdk/rev/33a0f66771d5
                                     
2011-01-17



Hardware and Software, Engineered to Work Together