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- customer  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
Posted Date : 2007-11-29 16:21:19.0

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
Posted Date : 2008-11-05 19:03:29.0

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.

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.
Posted Date : 2007-11-29 17:16:50.0

The suggested fix would be great, because applications which use XOR have most likely been developed in the java-1.1 age, and should also work find with the Software-only pipeline.

Here http://forums.java.net/jive/thread.jspa?threadID=39034&tstart=0 is a side effect of this one.

This bug also affects the library JFreeChart when using Java 6 update 10 RC. When the user drags the mouse in a chart to zoom into an area the drawing of the "zoom rectangle" is very slow and almost unbearable.

please disable it, when xor rendering is used

JDesktopPane.OUTLINE_DRAG_MODE is badly affected by this bug.

Oh man, what a tease! Our product could really benefit from the improved rendering of a D3D pipeline, but XOR painting is par for the course!

Any news whether this workaround will be implemented or not?

This regression introduced in update 10 is critical for us too. We tested update 11 and the preview of update 12 (build 02): still not fixed.

Hi,
I've encountered the same problem with u10 and u11. Unfortunately issuing "System.setProperty("sun.java2d.d3d", "false");" from my application as suggested in u10s release note to disable d3d has no effect on the disastrous XOR performance. I'm wondering that Sun is changing such basic behavior which makes the latest releases unusable in case an application relies on XOR-painting such as ours!

Without wanting to sound overly dramatic, have you any idea of the number of Swing applications and libraries you have broken with this bug? We have about 8,000 applications using JGraph, pretty much all of which will be broken. Please could someone look at this urgently?

This one hurts.

This should be a must-fix, since it breaks (or slows to a crawl) existing applications that depend on this functionality.

PLEASE FIX!

Please FIX ASAP...

This is also present in early release V7.  Please fix asap

Please fix it asap.

Please fix this ASAP! I'm building a workflow diagram applet and this bug has completely crippled it. I was hoping to release the first version of the software in mid Jan 09, but it looks like this won't happen now.

If you could disable D3D9 for Swing components, or add a mechanism to allow developers to dynamically enable/disable it at run time that would be a start.

We have switched off d3d-rendering for years now, since we have had bluescreens all the time on various systems.
Hoped it would come better, but this bug makes the new pipeline unusable again.

Is there any idea when this will be fix

I have a plotting tool that is also drag down on its feet when trying to draw the zoom box.  Please FIX!

We are advising all our customers not to install release 10 or higher of JRE 1.6.0 based on this problem.  It is not practical to instantly rip all XOR rendering out of an application with thousands of installed corporate users over years of product releases.  This kind of performance is totally unacceptable.

Please Fix it, asap
Thanks.

This bug is seriously affecting our commercial ListenUp Applet. We use XOR mode to draw a selection rectangle over a waveform. You can see the slow refresh by dragging the mouse over the waveform here:

http://www.javasonics.com/listenup/examples/record_insert.html

Please fix this ASAP.

the package i used calls
sun.java2d.SubGraphics3D.fill( java.awt.Shape )  ( actually a square )

Netbeans profiler show that
j6u6 does the filling itself, and the call tree ends like this;
650 times --> sun.java2d.pipe.LoopPipe.fill()    ( 390 ms = 4,8 % )
  650 times --> sun.java2d.pipe.LoopPipe.fillSpans() ( 1.47 ms = 0% )
     650 times --> sun.java2d.loops.FillSpans() Which is nice..

j6u10 on the other hand:
21 times --> sun.java2d.pipe.LoopPipe.fill()  (
  21 times --> sun.java2d.pipe.LoopPipe.fillSpans()
   ....
    88468 times --> java.awt.image.SinglePixelPackedSampleModel.getDataElements()  ( 47.9 ms =  0,3% )
      ......
      88468 times --> sun.java2d.d3d.D3DRenderQueue.flushBuffer()   ( 10002 ms = 71.9 %)
   
i did not check the stack trace for J6u12, but the drawing of the square is just as slow as J6u10

This bug has been resolved in 6u14b03 (early builds available from jdk6.dev.java.net).

Are there any details of the fix? Given the statement that "this is a known limitation of the current implementation because there is no easy way to express xor operation in D3D9", is this more a workaround?

The work around is that when XOR rendering is detected, the hardware acceleration for the destination surface is disabled forever.

Dmitri

This leaves our application which renders images from a camera useless.

> This leaves our application which renders images from a camera useless

Could you clarify how and why? And is it the bug, or the work around?

The workaround doesn't seem to be fixing the rendering problem in my scenario.  Basically, I've created a Swing-based Applet Viewer for an Oracle Forms applet (which I've found uses XOR rendering).

I'd like to be able to use AWTUtilities so the JFrame can have true rounded corners and a drop shadow.  However, as soon as I use AWTUtilities.setWindowOpaque(this,false) on the JFrame, the "sun.java2d.d3d" setting seems to be rendered useless, and the Oracle Forms applet inside the frame once again becomes slow to the point of inoperability.

Is there anything that I can do to still use AWTUtilities on the frame, but keep the XOR applet inside of the frame rendering properly?

Thanks in advance!

I doubt that this has anything to do with xor. Most likely you're running into performance issues with the implementation of translucent windows support in the jdk.

It's been improved in jdk7 b60 (see bug 6794764), the fix may be back ported to 6uXX.