JDK-5010944 : List's rows overlap one another
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0,6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS:
    linux_redhat_3.0,windows_2000,windows_2003,windows_xp linux_redhat_3.0,windows_2000,windows_2003,windows_xp
  • CPU: x86
  • Submitted: 2004-03-10
  • Updated: 2007-01-09
  • Resolved: 2005-08-06
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
6 b47Fixed
Related Reports
Relates :  
JDK-7152952 - [macosx] List rows overlap with enlarged font
Relates :  
JDK-4844952 - drawString corruption on Matrox video cards on linux
Relates :  
JDK-6248072 - Changing the selection mode of the list introduces an empty item at the end, on win32
Description
Regression: NO
Package: j2sdk
Version: 1.5.0-beta2-b41
Locale: DE

Description:
 After change "TextArea" to "List" the rows of List GUI element overlap one another. See attachment. It doesn't happen on Solaris platform (5.9 Generic_112233-11 sun4u sparc SUNW,Ultra-Enterprise)

Bundle tested:
 j2sdk-1_5_0-beta2-bin-b41-windows-i586-03_mar_2004.exe
 j2sdk-1_5_0-beta2-bin-b41-linux-i586-03_mar_2004.bin

Platform: 
  Windows: 2003 AS, DE
  Linux: RedHat 3.0AS
  
Test Suite: GlobalSuite 1.5 b05

Test Case:
  font-render/awt/two/CharViewMultiLine

Display Adapter:
  Windows: Matrox
  Linux: ATI 3D Rage Pro

Reproduce Step(s):
 - run 'sh run_gs.sh font-render/awt/two/CharViewMultiLine.java'
 - set font size 72
 - set 'TextArea'
 - set 'List'

Reproducible in previous build(s)?
 yes, b40

================================================================

Found also on Win XP Home (display adapter: Matrox): b42

###@###.### 2004-03-15
================================================================
Comments
EVALUATION verified on WinXP in 6.0 b103, fixed
09-01-2007
SUGGESTED FIX *** /net/aquila/export/dc158259/Mustang//webrev/src/solaris/classes/sun/awt/X11/XListPeer.java- 2005-07-14 15:35:24.000000000 +0400 --- /net/aquila/export/dc158259/Mustang//webrev/src/solaris/classes/sun/awt/X11/XListPeer.java 2005-07-14 15:35:24.000000000 +0400 *************** *** 1592,1597 **** --- 1592,1609 ---- return false; } + /* + * Fixed 5010944: List's rows overlap one another + * The bug is due to incorrent caching of the list item size + * So we should recalculate font metrics on setFont + */ + public void setFont(Font f){ + super.setFont(f); + initFontMetrics(); + layout(); + repaint(); + } + class ListPainter { // TODO: use VolatileImage VolatileImage buffer; ###@###.### 2005-07-18 10:48:56 GMT
18-07-2005
EVALUATION Name: ynR10250 Date: 03/11/2004 apparently duplicate of 4844952 ###@###.### ====================================================================== Name: ynR10250 Date: 03/15/2004 Unfortunately we have no Windows 2003 system available. Could you please file a separate bug for Windows 2003? Buggy behavior is not reproducible under Windows XP. As to XAWT, bug is due to List item size caching, and it's easy to fix. ###@###.### ====================================================================== The bug is reproducible under Windows XP Home, DE (without SP) too. Please, try to go via the 'Reproduce Steps' exactly - if you switch the steps (set font size at last), the buggy behavior doesn't appear. ###@###.### 2004-03-15 ====================================================================== I have attached a simple test in order to reproduce this problem on Linux. There are two separate issue about this bug: 1) Linux, 2) Windows (see 6248072 for more information, not fixed here). In order to reproduce this problem on Linux with the attached test case (ListTest) just press on the button 'setFont'. You will see that the rows of the list overlap one another. As mentioned before the bug on Linux is due to incorrent caching of the list item size. So we should recalculate font metrics on setFont. It's important that we don't need to update the font in other cases as distinct from Windows implementation (on Windows after setMode we create new list without the updating of the font but there is no the caching problem on Windows). That's why in order to reproduce this bug with GS test case on Windows we should set list on last step. ###@###.### 2005-07-18 10:48:55 GMT
18-07-2005