United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6512116 JTable column headers do not follow Windows ClearType (antialias) changes
JDK-6512116 : JTable column headers do not follow Windows ClearType (antialias) changes

Details
Type:
Bug
Submit Date:
2007-01-11
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
client-libs
OS:
windows_xp
Sub-Component:
javax.swing
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The column headers of a JTable correctly render in ClearType or regular fonts on Windows.  However, if I change from ClearType to non-smoothed fonts or vice versa, the JTable headers do not change.  (The JTable itself does change)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run SwingSet2 from the demo area
Click on the "JTable demo" button
Go to the Windows Control Panel, and double click the "Display" icon
Select the Appearance tab, and click on the "Effects..." button
  Toggle the checkbox "Use the following method to smooth edges of screen fonts"  to Off or to Clear Type
Click OK
Click the Apply button: this will update the JTable contents, but leaves the column headers unchanged

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expectation is that both the JTable contents and headers will update
ACTUAL -
Only the JTable contents update

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Use the demo\jfc\SwingSet2 demo code
---------- END SOURCE ----------

                                    

Comments
EVALUATION

Interesting. I already fixed this problem once under 6364555. The code that I added is still there. I'll have to track down what's causing the problem this time.
                                     
2007-01-12
EVALUATION

Yes, this was supposed to be fixed by 6364555. Unfortunately, a last-minute optimization tweak caused this problem.

In the JTableHeader class (and others), I had originally planned to add code like the following to updateUI(), to propogate the change to the renderer:

+       TableCellRenderer renderer = getDefaultRenderer();
+       if (renderer instanceof JComponent) {
+           ((JComponent)renderer).updateUI();
+       }

Instead, I added:

+       TableCellRenderer renderer = getDefaultRenderer();
+       if (!(renderer instanceof UIResource) && renderer instanceof Component) {
+           SwingUtilities.updateComponentTreeUI((Component)renderer);
+       }

My goal was to avoid updating the UI of any renderer that is a UIResource, thinking that it would be re-installed by the UI of the JTableHeader anyway. Unfortunately, the default renderer for JTableHeader is installed by the JTableHeader itself, AND it is a UIResource. As such, it's not safe to optimize this way.

I'll remove the check for UIResource in all places that I fixed for 6364555.
                                     
2007-01-17



Hardware and Software, Engineered to Work Together