|
Quick Lists
|
|
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
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |