JDK-6613066 : D3D: text is missing when the pipeline is enabled [ATI X1600]
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-10-04
  • Updated: 2010-10-14
  • Resolved: 2007-11-20
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 b08Fixed
Related Reports
Relates :  
JDK-6599742 - D3D: Text rendering becomes garbled on Intel 945G chipset
Relates :  
JDK-6687166 - D3D: text is missing when the pipeline is enabled [ATI Mobility X1400, Vista]
Description
Text is completely missing on HP laptop with ATI X1600 video chip.

[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal  : 0
[I] Description      : ATI Mobility Radeon X1600
[I] GDI Name, Driver : \\.\DISPLAY1, ati2dvag.dll
[I] Vendor Id        : 0x1002
[I] Version          : 6.14.10.6599
[I] ------------------
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[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_ALPHA_RT_PLAIN
[V]   | CAPS_ALPHA_RTT
[V]   | CAPS_OPAQUE_RTT
[V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER
[V]   | CAPS_MULTITEXTURE
[V]   | CAPS_TEXNONSQUARE
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u10/6613066.2
07-11-2007
EVALUATION More information found during the review: Now we only disable the pipeline on Windows XP or newer client-class OS-es. This excludes Win2003, Win2K, Win9x/ME, and Windows Server 2008. The reason for disabling this on Windows 2008 is that it doesn't even enable Aero theme by default - looks like a weird Win2k, actually (and there is no way to enable it) so clearly they don't care that much about graphics on the server. The driver for Windows Vista did install successfully on 2008, so it's possible that they will have the same drivers versions for both client and server - even though this is not relevant now. There is one more scenario I'd like to test. It's Win2008 Server with Terminal services enabled, with "Aero experience" enabled for the clients. I'm not quite sure how will that look like and whether it would use the local or remote hw acceleration in this case. I suspect that it would only be relevant to the WPF applications (xaml+c#) - so they will ship only xaml over the wire and render it on the client with hw acceleration. Obviously we will unlikely be able to use hw acceleration in this case which is why I'm filing the webrev even before trying this experiment (I don't expect terminal services to be easy to configure =) ------- Phil replied: > maybe it depends. Here, talking just about cleartype, > http://blogs.msdn.com/ts/archive/2006/09/08/747023.aspx > it sounds like there's extra server side processing for > GDI apps, and extra bandwidth needed > > But here http://msdn2.microsoft.com/en-us/windowsvista/aa905016.aspx > it sounds like WPF would use client-side acceleration Yes, like I said (this will require that both client and server are Vista or better). But since we're not a WPF app we will not benefit from this - to Windows we look just like some Direct3D (or GDI) application - we don't even do GDI to the screen, only blit to it. I've setup the Terminal Server and client in the lab. When connected to the server applications see local hw resources in some form. For example, Direct3D apps (including us) see a "RDPDD Chained DD" device with device/vendor id of 0x0000. We do successfully create the d3d device and everything works fine. However, it is rather slow (and I put an ATI 9800 Pro in the server, a pretty fast board) - even though both client and server are sitting next to each other in the same subnet. With D3D disabled the application works much snappier. In this case the client system had a board on which we do not enable d3d acceleration if run locally (it's a MX board). I think it is still a good idea to disable d3d for this (server-class OS) case - which we currently do since we detect that we're running on a server OS. Note that there is another scenario - when we do remote desktop from Vista to Vista. In this case we still enable d3d if the hw permits. And "hw" in this case is this Chained DD device. I've setup this configuration as well - two Vista systems, one Remote Desktop-ing to another (note that it's different from Terminal services case since there could be only one user RD-ing, but on a Terminal Server you can have multiple users logged in and working at the same time). So in this config both Vista systems had decent video boards and RD was showing as Aero, with composition effects enabled (not the default option). But I couldn't really see that much of a difference between running Java with D3D enabled and disabled - I've checked network utilization, cpu utilization. Interestingly, in say Java2D demo both CPUs (on client and server) were pegged. That kind of surprised me. Anyway, I think at this point we can leave it as is - allow d3d in Remote Desktop case. We can disable it later if needed. Another scenario I've tested is "net meeting" - the Vista version. In this case one can setup a meeting and then "share" some of applications or the whole desktop. To the remote participator it looks like some kind of VNC session. A direct3D application (us) in this case sees the real local device (ATI x1900 in this case), so we successfully initialized the Direct3D pipeline. Performance was fine either way - with or w/o d3d enabled. One thing though: if d3d application is "shared" Aero is disabled on the host system for the time the shared app is running. Any d3d app, not only us, so it's fine I assume.
06-11-2007
EVALUATION We have gone one step further and disabled the pipeline on server-class OSs and those older than Windows XP as they can not be relied on having the latest drivers, and it is unlikely that a server class system would need hw accelerated client rendering (and the drivers on server systems tend to be updated even less frequently).
06-11-2007
EVALUATION I've implemented the rejection based on driver version. So for this particular case the pipeline will not be enabled unless the driver is at least 6.14.10.6706 ..
30-10-2007
EVALUATION The system had an old driver - (from around beginning of 2006): [I] Description : ATI Mobility Radeon X1600 [I] Vendor Id : 0x1002 [I] Device Id : 0x71c5 [I] SubSys Id : 0x30a3103c [I] Driver Version : 6.14.10.6599 [I] GUID : {D7B71EE2-3285-11CF-4B6A-A910A1C2CB35} The latest driver from www.hp.com/support fixes the problem: [I] Description : ATI Mobility Radeon X1600 [I] Vendor Id : 0x1002 [I] Device Id : 0x71c5 [I] SubSys Id : 0x30a3103c [I] Driver Version : 6.14.10.6706 [I] GUID : {D7B71EE2-3285-11CF-BE69-A910A1C2CB35} Looks like we'll need to improve our hardware rejection code to check for the driver version.
26-10-2007