Bug ID: JDK-6659345 D3D: SGShape filled with RadialGP turns black when moved from one group to other

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6u10 b20Fixed

I have a SGShape added to a group - say 'Group A'. I have created a GaussianBlur and set 'Group A' as it's child. I have added the Effect node to another group - Say 'Group B' that constitutes the scene in the JSGPanel. Now on clicking the shape, I am adding the same shape directly to 'Group B' without explicitly removing it from 'Group A'. 
When I do this, the shape turns completely black. This is noticed only when I have an Effect on 'Group A' and only when the shape is filled with RadialGradientPaint. Not reproducible when the shape is filled with a solid color.

I reproduced it on WinXP with 6u10-b11, using Scenario 0.5. 

To reproduce the bug, run the attached test. You will see a rectangle filled with RGP. Click it. You will notice that the shape turns black completely. Click it again and it will be restored since it is added to the original parent on second click.

SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u10/6659345.0
10-03-2008
EVALUATION The reason this bug is not reproducible on the opengl pipeline is that when resetting the paint a RESET state is used instead of CHANGE. The analog in the D3D pipeline is STATE_OTHEROP - basically it is used to force the state change. Using STATE_OTHEROP in D3DPaints_ResetPaint will force the state change when the op is enabled. Then the RENDER_OP that follows will not reset the installed texture.
05-03-2008
EVALUATION OK, this is not related to 6594223, it's a bug in state management in the d3d pipeline. If we have a texture op followed by a paint op we reset the texture to null. This is due to the optimization in D3DContext::UpdateState. Here's the sequence prodiced from drawImage setPaint(RadialGradient) fillRect D3DBlitLoops_Blit UpdateState(0, 8) // old state, new state: STATE_CHANGE, TEXTURE_OP ... SetAlphaComposite UpdateState(8, 0) // the state is unchanged due to the optimizaiton SetRadielGradientPaint ResetPaint UpdateState(8, 0) // again, the state remains 8 SetTexutre(texture); D3DRenderer_FillRect UpdateState(8, 1) // TEXTURE_OP -> RENDER_OP state change SetTexture(NULL) D3DVC::FillRect() ... D3DVC::Render // rendering the textured quad but the texture is set to NULL Whether the bug manifests depends on the order of rendering operations. If a simple-colored fillRect is inserted between drawImage and fillRect then it works as expected because the state changes will be RENDER_OP // by fillRect STATE_CHANGE // by ResetPaint RENDER_OP // by fillRect - this time the texture is not reset // when the buffer is flushed later, rendering happens as expected // because the texture is not reset
05-03-2008
EVALUATION The bug is not related to the effects framefork's d3d backend, it's reproducible when running on just the d3d pipeline and sw effects. I wonder if this may be related to 6594223 - probably not though. More investigation needed.
04-03-2008
EVALUATION This only happens on 6u10 and appears to be a bug in the D3D renderer. When I set -noddraw=true or use an older JDK 6 then the problem goes away. Reassigning to Dmitri for further investigation and to file an appropriate JDK bug as needed.
04-03-2008