Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6659345
Votes 0
Synopsis D3D: SGShape filled with RadialGP turns black when moved from one group to other
Category java:classes_2d
Reported Against
Release Fixed 6u10(b20)
State 10-Fix Delivered, Verified, bug
Priority: 3-Medium
Related Bugs 6604903
Submit Date 05-FEB-2008
Description
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.
Posted Date : 2008-02-05 15:35:04.0
Work Around
N/A
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.
Posted Date : 2008-03-04 01:06:58.0

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.
Posted Date : 2008-03-04 01:51:58.0

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
Posted Date : 2008-03-05 00:02:08.0

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.
Posted Date : 2008-03-05 01:27:10.0
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang