JDK-6692817 : D3D: REGRESSION: Applet tab drawing is completely messed in 6u10
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-04-23
  • Updated: 2010-04-26
  • Resolved: 2008-05-03
Related Reports
Duplicate :  
Description
customer had noticed some severe drawing issues.  They are using a very old tab-pane library in some of these applets -- it comes from Symantec's (AWT, not Swing based) 
SFC classes from Visual Cafe.  These applets has worked fine for many years (since 
Java 1.1 through Java 6 Update 5 without issue).

The tab drawing is completely messed up in Update 10, though (in build 13 as well -- 
not test this earlier).  The area in which the tabs were to have resided shows a single
vertical grey line near the right of the region -- but the tabs still respond to mouse
clicks (if you can manage to hit what you can't see).

In another applet they still have an unresolved issue wherein they cannot resize the
100%x100% applet by resizing the browser frame *if* they have brought up an editing 
frame from this applet prior to the resize attempt.  This was identified as most likely
being a case where they were calling Swing APIs from outside the event dispatch thread.
Given that they cannot reproduce the issue in a small test applet.  they have not, ho
wever, managed to identify the misbehaved code, though.  This leads them to plead for 
some sort of special mode, e.g. possibly via assertions, whereby they could easily
ascertain where they are doing the wrong things in the wrong thread.  

Both sets of bugs lead them to plead for backwards compatibility in Java GUIs.  
If old GUIs must break for clean, fast, new GUI handling, then some sort of 
compatibility mode (e.g. via an applet parameter) or some tooling to help fix 
incompatible UIs is in order.  Having UIs just break between Update 5 and Update 10
without any firm ideas as to why or how to fix them is not good.

Machine configuration is a Dell M60 laptop with an NVIDIA Quadro FX graphics 
card with Windows XP.
Attached 3 screenshots showing the issue as compared to the issue not being present
when set either -Dsun.java2d.d3d.onscreen=false or -Dsun.java2d.d3d=false as well 
as the trace information on the drivers in question.  As requested they updated their
NVIDIA drivers to the latest available from Dell for their cards -- to no avail, 
this made no different whatsoever to the results.

Comments
EVALUATION The customer confirmed that the problem is not reproducible with the jdk with 6694230 fixed. Closing as duplicate of 6694230.
03-05-2008

EVALUATION Looks like this may be related to 6694230: D3D/OGL: Incorrect drawing behavior w/ 1.6u10 for components with overridden getInsets() The minimal test (attached) case shows the problem on builds prior to the one with the bug above fixed. We'll wait for customer verification before closing this bug.
29-04-2008

EVALUATION Adapters: on one system: [I] Description : NVIDIA Quadro FX 550 [I] GDI Name, Driver : \\.\DISPLAY1, nv4_disp.dll [I] Vendor Id : 0x10de [I] Device Id : 0x014d [I] SubSys Id : 0x34910de [I] Driver Version : 6.14.11.6939 [I] GUID : {D7B71E3E-420D-11CF-7568-422303C2CB35} another system: [I] Description : NVIDIA Quadro FX 550 [I] GDI Name, Driver : \\.\DISPLAY1 <DISPLAY1>, nv4_disp.dll [I] Vendor Id : 0x10de [I] Device Id : 0x014d [I] SubSys Id : 0x34910de [I] Driver Version : 6.14.10.8176 [I] GUID : {D7B71E3E-420D-11CF-9E6C-432303C2CB35} Likely to be caused by the on-screen rendering support in the new pipeline. I'm working with the customer on obtaining a test case. Disabling the pipeline addresses the issue. Unlikely to be driver caused because on one of the systems they have the latest driver.
23-04-2008

WORK AROUND -Dsun.java2d.d3d=false
23-04-2008