|
Quick Lists
|
|
Bug ID:
|
6691934
|
|
Votes
|
0
|
|
Synopsis
|
Nimbus L&F: Rotated Combobox dropdown and List causes appear black
|
|
Category
|
java:classes_2d
|
|
Reported Against
|
|
|
Release Fixed
|
6u10(b26)
|
|
State
|
10-Fix Delivered,
Verified,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
6530420
|
|
Submit Date
|
22-APR-2008
|
|
Description
|
When I rotate a Combobox and click on it to view its drop down, it appears black. Same is true for a rotated List.
This appears to be regression with the Nimbus L&F being set as default.
This is seen with 6u10 b14 on a WinXP Sp2 with the latest SDK build249.
Testcase and snapshot attached for reference.
Posted Date : 2008-04-22 11:02:34.0
When a clip is applied on a ComponentView with a List as component, portion of the List within the clip appears black. Reproducible with build 258. Run the below code to reproduce:
import javafx.gui.*;
Frame {
content: Canvas {
content: [Group {
content: [Circle {
centerX: 0
centerY: 0
radius: 105
fill: Color.RED
}]
}, Group {
clip: Circle {
centerX: 0
centerY: 0
radius: 105
}
content: [ComponentView {
component: List {
items: for (i in [1..9]) { ListItem { text: "ListItem{i}" } }
}
translateX: 50
translateY: 50
}, ComponentView {
component: Button {
text: "Click Me"
}
translateX: 50
translateY: 15
}]
}]
}
width: 300
height: 300
visible: true
};
Posted Date : 2008-04-23 11:16:19.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
I was able to reproduce this on XP, but not on Vista. Re-assigning to scenegraph team to investigate.
Posted Date : 2008-04-23 16:23:52.0
Attached a pure Java test case. Test it with Scenario.jar in your classpath. I used build #172. Did not include any of the native binaries. Just Scenario.jar. Attachments show results on XP and Vista.
Will follow-up with system info.
Posted Date : 2008-04-23 17:36:30.0
XP system info:
XP Professional SP2
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b22)
[I] OS Version = OS_WINXP Pro
[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal : 0
[I] Adapter Handle : 0x10001
[I] Description : NVIDIA GeForce4 MX 440 with AGP8X
[I] GDI Name, Driver : \\.\DISPLAY1, nv4_disp.dll
[I] Vendor Id : 0x10de
[I] Device Id : 0x0181
[I] SubSys Id : 0x0
[I] Driver Version : 6.14.10.8421
[I] GUID : {D7B71E3E-42C1-11CF-5543-0A2060C2CB35}
[E] D3DPPLM::CheckDeviceCaps: adapter 0: Failed (pixel shaders 2.0 required)
[I] ------------------
[E] D3DPPLM::CheckAdaptersInfo: no suitable adapters found
[E] InitD3D: failed to init adapters
Posted Date : 2008-04-23 17:42:27.0
Vista system info:
Vista Business
Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b22)
[I] OS Version = OS_VISTA or newer
[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal : 0
[I] Adapter Handle : 0x10001
[I] Description : NVIDIA GeForce 7900 GS
[I] GDI Name, Driver : \\.\DISPLAY1, nvd3dum.dll
[I] Vendor Id : 0x10de
[I] Device Id : 0x0292
[I] SubSys Id : 0x37010de
[I] Driver Version : 7.15.11.6375
[I] GUID : {D7B71E3E-41D2-11CF-896B-7B2301C2CA35}
[I] D3DPPLM::CheckDeviceCaps: adapter 0: Passed
[I] ------------------
[I] D3DGD_getDeviceCapsNative
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[V] dwBehaviorFlags=D3DCREATE_FPU_PRESERVE|D3DCREATE_HARDWARE_VERTEXPROCESSING
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[I] D3DContext::InitDefice: successfully initialized device 0
[V] | CAPS_DEVICE_OK
[V] | CAPS_RT_PLAIN_ALPHA
[V] | CAPS_RT_TEXTURE_ALPHA
[V] | CAPS_RT_TEXTURE_OPAQUE
[V] | CAPS_LCD_SHADER | CAPS_BIOP_SHADER | CAPS_PS20
[V] | CAPS_PS30
[V] | CAPS_MULTITEXTURE
[V] | CAPS_TEXNONPOW2
[V] | CAPS_TEXNONSQUARE
Posted Date : 2008-04-23 17:45:03.0
Important note: Turning off d3d on Vista makes the problem appear.
Posted Date : 2008-04-23 17:45:21.0
The bug is reproducible with regular Swing application (attached),
only with Nimus look and feel.
The test just renders a list into a BufferedImage with transform
set.
Posted Date : 2008-04-23 23:10:53.0
The problem is that Nimbus makes use of a Color subclass which changes
its rgb value over time (by overriding getRGB() method and returning
a different value).
This is not an intended use of the Color class which is supposed
to be immutable. It is unfortunate that it has not been made final
so this can't be changed now.
There are a few places in the Java2D code which use the 'value' field of Color
class directly:
- native BlitBg retrieves the bg color's rgb value directly from
native code
- when a PaintContext is created in Color class - which affects
this particular case because the paint context is used by the
AlphaPaintPipe (which is used in this case because of the complex
clip)
- a xor color's value is accessed in GDIWinSD_InitDC via
GrPrim_CompGetXorColor
We'll address these cases, but it is by no means and endorsement of
the practice of subclassing Color with the intent of changing its
rgb value over time.
These fixes will not address the case when the rgb value is changed
while rendering to the same graphics context - the rendering results
will not be correct in this case.
Note that in Java 7 the second case is already addressed by the fix
for 6530420, but the fix for 6u10 will not be a direct backport.
Posted Date : 2008-05-29 21:33:19.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |